Ion braginskii fluid #263
Ion braginskii fluid #263
Conversation
…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)
|
I think the test failures are unrelated to this PR. The version of OpenMPI we get for the tests seems to have been updated to v5, and that changed some configuration parameters - see open-mpi/ompi#8955. I'll make a separate PR to fix that. |
|
I see, thanks for letting me know! |
…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)
|
Does this option also support using the collisional coefficients derived from the Fokker-Planck operator? The name "Braginskii" here might be misleading, when I think Braginskii electrons do use the Fokker-Planck coefficients, instead of the Krook ones. |
|
After discussing it with John and Sarah, I think the most consistent naming would be for us to call it |
|
Sounds good to me! I would stick to using all underscores or all hyphens in the string input parameter. Strings like |
|
I don't know why I wrote |
…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
| if :ir ∈ keys(kwargs) && isa(kwargs[:ir], mk_int) | ||
| for it ∈ 1:size(variable, 3) | ||
| @views derivative!(variable[:,:,it], T[:,:,it], run_info.z, run_info.z_spectral) | ||
| end | ||
| else | ||
| for it ∈ 1:size(variable, 4), ir ∈ 1:run_info.r.n | ||
| @views derivative!(variable[:,:,ir,it], T[:,:,ir,it], run_info.z, run_info.z_spectral) | ||
| end | ||
| end |
There was a problem hiding this comment.
I think this one, and also "dn_dz" and "dupar_dz", need a loop over species (in case there are multiple ion species). That would lead to 4 different cases depending on if is and/or ir is an integer. I think the following would be better, although the use of CartesianIndices is a bit more cryptic than I'd like
for i ∈ CartesianIndices(selectdim(variable, 1, 1))
@views derivative!(variable[:,i], T[:,i], run_info.z, run_info.z_spectral)
end@LucasMontoya4 what do you think?
There was a problem hiding this comment.
That seems like a pretty nice solution to me! Sorry about that, I was being lazy and avoiding writing multiple species functionality…
| n = get_variable(run_info, "density"; kwargs...) | ||
| vth = get_variable(run_info, "thermal_speed"; kwargs...) | ||
| dT_dz = get_variable(run_info, "dT_dz"; kwargs...) | ||
| nu_ii = get_variable(run_info, "collision_frequency_ii"; kwargs...) | ||
| variable = @. -(1/2) * 5/4 * n * vth^2 * dT_dz / nu_ii |
There was a problem hiding this comment.
If we introduce a function for the inside of the loop in calculate_ion_qpar_from_braginskii!() we could re-use it here, like
function _calculate_ion_qpar_from_braginskii_inner(density, vth, nu_ii, dT_dz)
return @. -(1/2) * 5/4 * density[iz,ir] * vth[iz,ir]^2 /nu_ii * dT_dz[iz,ir,1]
endThe @. should mean this function works for either scalar inputs (like in calculate_ion_qpar_from_braginskii!()) or array inputs (like here).
There was a problem hiding this comment.
Sounds great to me. There are a few other cases of re calculating things in the ‘load_data.jl’ file, so there might be a nicer way to revamp all of that function?
| conductive_heat_flux = total_heat_flux - 2.5 * this_ppar * this_upar - | ||
| 0.5 * this_dens * this_upar^3 |
There was a problem hiding this comment.
I think we need to check whether this is 5/2 or 3/2 in a 1V case... Can check by working out the total heat flux from \int dvpa vpa * 1/2 * vpa^2.
There was a problem hiding this comment.
You're right, I should have checked this earlier! Since ppar is only defined as \int dwpa m wpa^2 f , rather than one third of that in the 3d isotropic pressure case, it is only 3/2 instead of 5/2.
Preliminary ion code, where braginskii for krook operator is used to calculate heat flux. Ions can now be
drift_kinetic_ions,gyrokinetic_ions(which replaced thegyrokinetic_ions = trueflag) orbraginskii_ions. The boundary condition is set from the Stangeby book on total energy flux for ions.There is also a plotting system for
collisionality_plots, which compares gradient length scales to the mean free path (to establish how collisional you are). Options in thepost_processing_input.tomlfile can be found in theset_defaults_check_section!()part of the_setup_single_input()function that callscollisionality_plots