Krook 'collisions' #127

johnomotani · 2023-09-11T19:05:42Z

Add a Krook collision operator. Needed this to make 1D1V simulations look nicer for EFTC!

Also includes a script to print some dimensional parameters from a simulation (e.g. ion-ion collision frequency).

TODO:

test - at least a regression test, including the moment-kinetic versions, is needed

mrhardman · 2023-09-12T09:09:48Z

I have separately developed Krook collision operator code for 1V and 2V, and extended the manufactured solutions tests to accommodate this feature. The relevant commits are

6bd406e
d5c366f
97c788e
a6f06cc

This allows them to be called in other modules in a setup function, which can then be called in moment_kinetics_input.jl, avoiding an unresolvable cyclic import.

This is a litle bit cleaner, and allows setup of settings from input to use the coordinate objects.

These require interpolation in the velocity grids to compare to the expected distribution function values.

Test is based on the NonlinearSoundWave test, but with Krook collisions added. Only test Chebyshev derivatives (not finite difference) to save time, as derivatives are not used in the Krook collision operator.

If there is a vperp dimension (i.e. ion distribution function is not marginalised over vperp) then need a prefactor of 1/vth^3 rather than 1/vth (as for the 1V case) in front of the Maxwellian.

johnomotani · 2023-09-22T12:58:57Z

@mrhardman I'm proposing to merge this PR, as this Krook collision operator supports moment-kinetic modes, and has a density/temperature dependent collision frequency. Are you OK with that? It will need some merging with your MMS tests when you make a PR for those.

mrhardman · 2023-09-25T07:54:21Z

@mrhardman I'm proposing to merge this PR, as this Krook collision operator supports moment-kinetic modes, and has a density/temperature dependent collision frequency. Are you OK with that? It will need some merging with your MMS tests when you make a PR for those

I would prefer the MMS test options to be included now, since it seems that you only have a regression test here. The MMS tests are quite orthogonal to the rest of my collision operator development in that branch. Can we discuss offline what the barriers to including the MMS tests are?

johnomotani · 2023-09-25T09:31:12Z

@mrhardman I don't see any barrier to adding the MMS test. Please feel free to push it onto this branch. I wanted to add the regression test as something that would be run in the CI, as we don't have that set up for any of the MMS tests yet, and they may be too computationally heavy to run in CI anyway.

src/krook_collisions.jl

mrhardman · 2023-09-25T10:23:06Z

src/moment_kinetics_input.jl

@@ -197,27 +92,26 @@ function mk_input(scan_input=Dict(); save_inputs_to_txt=false, ignore_MPI=true)
    composition.Er_constant = get(scan_input, "Er_constant", 0.0)

    # Get reference parameters for normalizations
-    reference_parameter_section = set_defaults_and_check_section!(
+    reference_parameter_section = copy(set_defaults_and_check_section!(


This is probably the wrong place to discuss this, but I don't understand why we need reference parameters in the code itself.

My reasoning is that we need the reference parameters to calculate the collision frequency, so for me it's easier to understand if it's explicit what the reference parameters are for a given simulation (i.e. given in the input file or set by defaults), and 'everything else' is forced to be consistent with them. At the moment it's 'just' (I guess?) rhostar and collision frequency at reference parameters that are actually being used, but at some point we might need/want for example atomic rates (ionization, charge exchange, etc.) that are tabulated functions of density and temperature.

Another motivation is that we might want a post processing routine that calculates things in SI units, like the heat flux to the target (in MW/m^2), or the power input into the simulation (in MW). Then we'd need to know what the reference parameters are, so it's simplest if they are explicitly specified.

What's the downside of having reference parameters specified?

mrhardman · 2023-09-25T10:39:20Z

src/krook_collisions.jl

+            else
+                vth_prefactor = 1.0 / vth^3
+            end
+            nu_ii = collisions.krook_collision_frequency_prefactor * n * T^(-1.5)


This choice of prefactor is probably motivated by the physical form of Fokker-Planck collision frequency, but it is not obvious to me that we would actually want this feature. Isn't it easier to understand the ad-hoc feature that we add if it doesn't have a nonlinear collision frequency?

I think it makes sense to have both options (e.g. Gkeyll does that https://gkeyll.readthedocs.io/en/latest/gkyl/App/Collisions/collisionModels.html). If you want to add an option for constant collision frequency I'm happy for that to be there. I wanted to have a density/temperature dependent collision frequency because in a setup where physically the collisionality changes significantly (e.g. due to a large temperature drop between midplane and target) I don't want to have unphysically strong collisions upstream, but want the collisions near the target to be strong enough to Maxwellian-ise the plasma.

mrhardman · 2023-09-25T11:24:29Z

I am starting to merge in the appropriate features. The job may take some time as even the manufactured solutions module appears to have diverged from the initial state where d5c366f was committed to. If this merge is urgent, we should discuss.

src/krook_collisions.jl

johnomotani · 2023-09-25T11:33:33Z

src/krook_collisions.jl

+            else
+                vth_prefactor = 1.0 / vth^3
+            end
+            nu_ii = collisions.krook_collision_frequency_prefactor * n * T^(-1.5)


I think it makes sense to have both options (e.g. Gkeyll does that https://gkeyll.readthedocs.io/en/latest/gkyl/App/Collisions/collisionModels.html). If you want to add an option for constant collision frequency I'm happy for that to be there. I wanted to have a density/temperature dependent collision frequency because in a setup where physically the collisionality changes significantly (e.g. due to a large temperature drop between midplane and target) I don't want to have unphysically strong collisions upstream, but want the collisions near the target to be strong enough to Maxwellian-ise the plasma.

johnomotani · 2023-09-25T11:49:22Z

src/moment_kinetics_input.jl

@@ -197,27 +92,26 @@ function mk_input(scan_input=Dict(); save_inputs_to_txt=false, ignore_MPI=true)
    composition.Er_constant = get(scan_input, "Er_constant", 0.0)

    # Get reference parameters for normalizations
-    reference_parameter_section = set_defaults_and_check_section!(
+    reference_parameter_section = copy(set_defaults_and_check_section!(


My reasoning is that we need the reference parameters to calculate the collision frequency, so for me it's easier to understand if it's explicit what the reference parameters are for a given simulation (i.e. given in the input file or set by defaults), and 'everything else' is forced to be consistent with them. At the moment it's 'just' (I guess?) rhostar and collision frequency at reference parameters that are actually being used, but at some point we might need/want for example atomic rates (ionization, charge exchange, etc.) that are tabulated functions of density and temperature.

Another motivation is that we might want a post processing routine that calculates things in SI units, like the heat flux to the target (in MW/m^2), or the power input into the simulation (in MW). Then we'd need to know what the reference parameters are, so it's simplest if they are explicitly specified.

What's the downside of having reference parameters specified?

2V Krook collisions are now implemented for full-f simulations.

mrhardman · 2023-09-25T12:15:48Z

What's the downside of having reference parameters specified?

So long as it is clear that all evolved quantities are normalised, I will have to be happy. In HPC codes that I have worked with previously all small numbers are eliminated from the equations in favour of normalised parameters which enter the input file, and are computed externally to the HPC code. This also gave the option of making physics studies where unphysical parameter scans can be supported (changing the mass of particles, but not collision frequency, for example). In an ideal implementation we would use all reference parameters in a separate module and not propagate their use into the main code, where only normalised quantities are used. This might be what you are already doing -- in which case I cannot find fault.

…ant frequency coefficient).

…k operator. Check-in tests still fail for undiagnosed reasons.

This is needed since 'sqrt spacing' option was added. Also include velocity_integral_tests.jl in runtests.jl so that it is included in the CI tests. Also remove some println() statements that had been left in by mistake.

Set irank/nrank as if running in serial, to avoid errors from set_element_scale_and_shift()).

src/krook_collisions.jl

This option now passes the tests, so might as well make it the suggested option.

Krook collisions manufactured solutions test port

johnomotani

Make clearer that T_over_Tref is not the normalised temperature as defined in the code.

src/krook_collisions.jl

...with the current normalisations used by the code, which normalise pressure by `mref*Nref*cref^2 = 2*Nref*Tref`.

mrhardman · 2023-10-31T07:53:43Z

Make clearer that T_over_Tref is not the normalised temperature as defined in the code.

Why not avoid using T_over_Tref entirely and put

n * vth^(-3)

in the collision operator factor?

mrhardman

Regarding making the "reference parameters" option default for the MMS tests: Do we have a diagnostic output for what the actual collision frequency used is for this option? This could be helpful for understanding whether or not the inputs give O(1) coefficients in the MMS test. I think the default ended up being ~ 0.95.

johnomotani · 2023-10-31T09:24:44Z

Implementing collision operator in terms of vth - I like that idea. I guess however we end up defining cref, we'd choose to have vth(norm) = vth(unnorm)/cref, so the implementation in terms of vth would keep working for any choice.

Diagnostic output for collision frequency - that would be useful, and should be an easy thing to implement.

This means that to calculate the normalised, spatially-varying collision frequency we multiply by (the normalised) n/vth^3, and do not need to worry about potentially changing normalisation of T (to mref*cref^2 or to Tref).

Makes it easier to reuse in future (e.g. for post processing).

Need to add an `element_spacing_option` argument for the dummy coordinate input.

...rather than handling ad-hoc in `plots_for_variable()`. This is cleaner, and makes it possible when using makie_post_processing interactively to easily get "temperature", "collision_frequency", etc.

johnomotani · 2023-10-31T10:40:33Z

...both upgrades now made.

After adding a function that calculates collision frequency (and a little bit of refactoring of makie_post_processing), adding plots of the collision frequency in makie_post_processing only took 9 lines 😎

moment_kinetics/src/makie_post_processing.jl

Line 73 in c7735e1

"collision_frequency")

moment_kinetics/src/makie_post_processing.jl

Lines 1210 to 1213 in c7735e1

    
           elseif variable_name == "collision_frequency" 
        
               n = postproc_load_variable(run_info, "density") 
        
               vth = postproc_load_variable(run_info, "thermal_speed") 
        
               variable = get_collision_frequency(run_info.collisions, n, vth)

moment_kinetics/src/makie_post_processing.jl

Lines 1333 to 1336 in c7735e1

    
           elseif variable_name == "collision_frequency" && 
        
                   all(ri.collisions.krook_collisions_option == "none" for ri ∈ run_info) 
        
               # No Krook collisions active, so do not make plots. 
        
               return nothing

johnomotani · 2023-10-31T10:54:24Z

PS the spatially-varying collision frequency is O(1), at least in the 1V test

johnomotani added the enhancement New feature or request label Sep 11, 2023

johnomotani force-pushed the makie-unnormalised-f branch from 991ce1e to b97fa48 Compare September 12, 2023 08:20

johnomotani force-pushed the Krook-collisions branch from c33950a to e8c4980 Compare September 12, 2023 08:20

johnomotani force-pushed the makie-unnormalised-f branch from b97fa48 to 32b3f48 Compare September 12, 2023 11:05

johnomotani force-pushed the Krook-collisions branch from e8c4980 to 0bf42de Compare September 12, 2023 11:05

johnomotani force-pushed the makie-unnormalised-f branch from 32b3f48 to 35f3ea4 Compare September 12, 2023 20:46

johnomotani force-pushed the Krook-collisions branch from 0bf42de to 0883a6e Compare September 12, 2023 20:49

johnomotani force-pushed the makie-unnormalised-f branch from 35f3ea4 to 6f2b9b6 Compare September 13, 2023 08:52

johnomotani added 6 commits September 13, 2023 10:02

Move generic settings definition functions to input_structs.jl

bffaea3

This allows them to be called in other modules in a setup function, which can then be called in moment_kinetics_input.jl, avoiding an unresolvable cyclic import.

Move define_coordinate() calls into mk_input()

6293496

This is a litle bit cleaner, and allows setup of settings from input to use the coordinate objects.

Add module with physical constants, mk_input return reference_parameters

fdac38e

Function to print some dimensional parameters of a simulation

df1bd5b

Script to compare collision frequencies to numerical dissipation

33584ea

Krook collision operator for ion-ion Coulomb collisions

8d8bcd4

johnomotani force-pushed the Krook-collisions branch from 0883a6e to 8d8bcd4 Compare September 13, 2023 09:02

Base automatically changed from makie-unnormalised-f to master September 13, 2023 11:26

johnomotani added 3 commits September 22, 2023 13:17

Implement "split 2" and "split 3" test for NonlinearSoundWaveTests

94e1408

These require interpolation in the velocity grids to compare to the expected distribution function values.

Add regression test for Krook collision operator

fcdd763

Test is based on the NonlinearSoundWave test, but with Krook collisions added. Only test Chebyshev derivatives (not finite difference) to save time, as derivatives are not used in the Krook collision operator.

Handle 2V case in Krook collision operator

9b21e09

If there is a vperp dimension (i.e. ion distribution function is not marginalised over vperp) then need a prefactor of 1/vth^3 rather than 1/vth (as for the 1V case) in front of the Maxwellian.

mrhardman reviewed Sep 25, 2023

View reviewed changes

src/krook_collisions.jl Outdated Show resolved Hide resolved

mrhardman reviewed Sep 25, 2023

View reviewed changes

johnomotani commented Sep 25, 2023

View reviewed changes

Restrict check for 1V in Krook collisions to moment-kinetic cases

cf8a956

2V Krook collisions are now implemented for full-f simulations.

mrhardman and others added 11 commits October 30, 2023 11:08

Example input files for MMS test with Krook operator (spatially const…

6132fc6

…ant frequency coefficient).

Change input options for Krook so that default is to not use the Kroo…

1885c79

…k operator. Check-in tests still fail for undiagnosed reasons.

Fix figure saving for 1D plot in makie_post_processing

5647180

Pass nvperp to manufactured solutions funcs in makie_post_processing

7ed8a1c

Convert test_velocity_integrals.jl to a CI test

a6771e5

Merge branch 'master' into Krook-collisions-MMS-port

5130cf8

Merge branch 'Krook-collisions' into Krook-collisions-MMS-port

a8e314d

Deactivate Krook collisions by default

6884d86

Better values for MPI variables when ignore_MPI=true in mk_input()

afe3709

Set irank/nrank as if running in serial, to avoid errors from set_element_scale_and_shift()).

Tidy up comments

5d5ddaf

johnomotani commented Oct 30, 2023

View reviewed changes

johnomotani added 3 commits October 30, 2023 19:58

Make clearer that Ti_over_Tref is not normalised temperature

8a5e298

Krook MMS test inputs use spatially-varying collision frequency

4c9e810

This option now passes the tests, so might as well make it the suggested option.

Merge pull request #141 from mabarnes/Krook-collisions-MMS-port

49e33d1

Krook collisions manufactured solutions test port

johnomotani commented Oct 30, 2023

View reviewed changes

Make clearer that T_over_Tref is not normalised temperature

1654f7c

...with the current normalisations used by the code, which normalise pressure by `mref*Nref*cref^2 = 2*Nref*Tref`.

johnomotani requested a review from mrhardman October 30, 2023 20:07

mrhardman reviewed Oct 31, 2023

View reviewed changes

johnomotani added 5 commits October 31, 2023 10:04

Move calculation of Krook collision frequency to a function

37856fa

Makes it easier to reuse in future (e.g. for post processing).

Make plots of collision frequency if Krook collisions are used

eff2647

Fix coordinate creation in makie_post_processing

326efbb

Need to add an `element_spacing_option` argument for the dummy coordinate input.

Handle derived variables in get_variable() in makie_post_processing

c7735e1

...rather than handling ad-hoc in `plots_for_variable()`. This is cleaner, and makes it possible when using makie_post_processing interactively to easily get "temperature", "collision_frequency", etc.

johnomotani merged commit fc6da74 into master Nov 1, 2023
8 of 21 checks passed

johnomotani deleted the Krook-collisions branch November 1, 2023 12:37

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Krook 'collisions' #127

Krook 'collisions' #127

johnomotani commented Sep 11, 2023 •

edited

Loading

mrhardman commented Sep 12, 2023

johnomotani commented Sep 22, 2023

mrhardman commented Sep 25, 2023

johnomotani commented Sep 25, 2023

mrhardman Sep 25, 2023

johnomotani Sep 25, 2023

mrhardman Sep 25, 2023

johnomotani Sep 25, 2023

mrhardman commented Sep 25, 2023

johnomotani Sep 25, 2023

johnomotani Sep 25, 2023

mrhardman commented Sep 25, 2023

johnomotani left a comment

mrhardman commented Oct 31, 2023

mrhardman left a comment •

edited

Loading

johnomotani commented Oct 31, 2023

johnomotani commented Oct 31, 2023

johnomotani commented Oct 31, 2023

Krook 'collisions' #127

Krook 'collisions' #127

Conversation

johnomotani commented Sep 11, 2023 • edited Loading

mrhardman commented Sep 12, 2023

johnomotani commented Sep 22, 2023

mrhardman commented Sep 25, 2023

johnomotani commented Sep 25, 2023

mrhardman Sep 25, 2023

Choose a reason for hiding this comment

johnomotani Sep 25, 2023

Choose a reason for hiding this comment

mrhardman Sep 25, 2023

Choose a reason for hiding this comment

johnomotani Sep 25, 2023

Choose a reason for hiding this comment

mrhardman commented Sep 25, 2023

johnomotani Sep 25, 2023

Choose a reason for hiding this comment

johnomotani Sep 25, 2023

Choose a reason for hiding this comment

mrhardman commented Sep 25, 2023

johnomotani left a comment

Choose a reason for hiding this comment

mrhardman commented Oct 31, 2023

mrhardman left a comment • edited Loading

Choose a reason for hiding this comment

johnomotani commented Oct 31, 2023

johnomotani commented Oct 31, 2023

johnomotani commented Oct 31, 2023

johnomotani commented Sep 11, 2023 •

edited

Loading

mrhardman left a comment •

edited

Loading