Add PI_controller for temperature, update PI_controller for density, and add coll_krook heat flux closure #284
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…with update_neutral_qz
…nskii ion physics. Gyrokinetic flag replacement of the gyrokinetic_ions case will happen in a later commit, so right now the gyrokinetic option for ion_physics does the same as drift_kinetic.
…gyrokinetic_ions = true being the test, we see whether ion_physics == gyrokinetic_ions
…nnormalised pdf (then subsequent heat flux updates will be with the braginskii closure)
…the struct, as well as an ion temp
….jl to use the reference collision frequency to calculate braginskii heat flux
…mean free path) and braginskii heat flux boundary condition at walls, following Stangeby (though I haven't checked the subtracted part for conductive heat flux yet).
…small correction to ion braginskii heat flux boundary condition
…ocstring for collisionality_plots function in makie_post_processing
…source_controller_integral is still unused
…ginally hard coded)
…hat run (for when heat flux in the simulation is calculated using the shape function - having this option for braginskii_ions would just plot the same thing twice)
…nd power in upstream external source. Might add higher powers later.
… braginskii one (which just overplots the old one, apart from the boundaries)
…hich is much clearer than just writing braginskii everywhere. Note that I will soon change the naming system to collisional_krook
…etics into ion_braginskii_fluid
…ource with an input guess, which is the source_strength option in the input file. This means when you restart a run from another that had a constant external source, that choice of starting point for the PI_controller source should mean the PI_controller doesn't have to do too much work (as long as the target amplitude is not very far from the current midpoint amplitude).
…tances of the name braginskii for ion functions to coll_krook. The electron braginskii fluid naming is unchanged for now.
…k coefficient calculation.
…numbers of timesteps
…ixed in previous commit)
…rid and nelement can both be 1 (to speed up process easily). Also change gamma_i to 4.0 for stability of more dense cases in collisionality scans.
…ux of coll_krook calculation to reflect the 1D pressure rather than 3D isotropic pressure used. Also comment out line where boundary_conditions.jl is used in krook_collisions.jl since I need to use krook_collisions.jl in the velocity_moments.jl module. THIS IS NOT A WORKAROUND AND NEEDS TO BE FIXED AT SOME POINT.
… collisions module can be defined later in moment_kinetics.jl. This fixes the issue highlighted in the previous commit.
…amplitude of an energy source so that the temperature midpoint is kept at a desired level. A few notes on this for now: 1. The temperature of the source has to be higher than the desired temperature, otherwise it can never be made hot enough, no matter how high the input amplitude. 2. The temperature of the source actually needs to be at least DOUBLE the desired value, which I think is coming from a factor of 2 error somewhere - this should be fixed when I comb through all the stuff I've written to iron out these missing factors of 2 one day. 3. This currently only really works for the ion fluid case - something has gone wrong with the part that actually adds to the pdf. I'll try to fix this soon.
…pending on whether we're 1V or 2V
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The PI controller for density has been updated, and one has been made for temperature, so now a simulation can be forced towards a desired temperature and density midpoint. Note that the PI controller for temperature is not quite perfect yet - it is a copy of the energy source, but the
evolve_moments = falseseems to not converge in the same way asevolve_moments = truefor the moment_kinetic case.There is also now a loop in
euler_time_advance!that checks if we are usingcoll_krook_ionsor not. This makes the code for acoll_krooksimulation run around 75% faster (since the shape function is never used). However, there are still many pieces of code (such as the boundary condition checks) that will carry around the shape function anyway, and some of these are still necessary for the moment boundary conditions. Hence, instead of rewriting lots of functions to have extra loops checking for the ion physics, the easiest route is to just set thevpan_gridandn_elementboth to 1. This makes the fluid run around 60 times faster than a kinetic run. The limit would be around 200 times faster (depending on what yourvpagrid resolution was), so this seems adequate for now.