Enumerate use-cases for zero-fluid configurations and design matching configure.py options

[felker]

Is your feature request related to a problem? Please describe.

On the bvals_pscalars branch, I have added a --nscalars=N flag to configure.py. Of course, this is sufficient to specify a solver configuration that encompasses:

• Fluid (Hydro or MHD) + passive scalars + etc.

But, as we have discussed frequently at this week's UNLV Athena++ Meeting, there are many applications for which it would be desirable to configure solver with no fluid. Before I begin splitting up the Hydro class and adding conditionals throughout mesh/ and task_list/ to make this possible, @jmstone was thinking it would first be useful to list all the high-priority / most common use-cases of such a capability. Perhaps that will lead to a better design for configure.py flag(s) other than --no-fluid or --fluid=true/false.

What configurations would users like to use? Some thoughts:

• No fluid + passive scalars
  • Useful for regression or unit tests that focus on reconstruction. See Mignone (2014) for the long-desired tests of the PLM and PPM limiter correction terms for curvilinear coordinates.
  • In which class should the specified background velocity field live? How should the user specify the setup?
• No fluid + particles (dust, Monte Carlo radiation, etc.)
• No fluid + nothing else
  • By providing HDF5 input for --prob=from_array, Athena++ could act as a powerful tool to analyze static data sets (compute complicated GR transformations, post-processing, etc.)

[c-white]

• No fluid + any radiation
  • Useful for any tests - not just regression, but also to see if a radiation scheme is appropriate for a problem.
  • Would still be rather nontrivial in GR.

[munan]

Just to confirm: "no fluid" means no fluid integrator (the fluid variables are fixed throughout the simulation), but the fluid variables are initialized, right?

• No fluid + chemistry + radiation: post-processing chemistry

On Thu, Mar 21, 2019 at 11:01 PM Chris White notifications@github.com wrote:

• No fluid + any radiation
  • Useful for any tests - not just regression, but also to see if a radiation scheme is appropriate for a problem.
  • Would still be rather nontrivial in GR.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/PrincetonUniversity/athena/issues/247#issuecomment-475504228, or mute the thread https://github.com/notifications/unsubscribe-auth/ACt0n-X1pFY6DafEWeTSsDjxRA2LOrOvks5vZHG4gaJpZM4cCV7j .

[tomidakn]

I can imagine both cases, like PIC where no fluid is involved at all.

[alwinm]

Particles + self gravity (but will need an array for Potential and an array for Density that the particles are deposited on). Useful for self-consistently calculating the gravitational potential due to particles-only.

Explanation: I doubt this is high-priority or most common, but eventually there will be sink/star particles in Athena++ as there are in Athena 4.2, whose self-gravity may be computed by deposition onto a grid -> FFT -> Phi, and it would be most self consistent to use the simulation's treatment of gravity to analyze the output. A post-processing script can be used to compute the particle-only gravitational potential (I needed this to separate star particle contribution from gas contribution).

When using MPI, memory-per-node may not be an issue, but being able to easily control which fields are initialized seems like it would help reduce memory requirements when postprocessing large simulations esp. on single nodes. But that might be more trouble than its worth to implement.

[msbc]

The eos_test.cpp pgen has no need for hydro. However the EOS settings in the input file are in the hydro block.

[felker]

When we last spoke, @jmstone was leaning towards making the fluid switch a runtime option, not a compile-time flag. I think that this makes some sense, depending on how we handle compile-time macro constants NHYDRO and NWAVE.

E.g. on the Wiki page The Input File:

• <hydro> (mandatory) : parameters of hydrodynamics
  • active (optional) : switch to dynamically integrate a fluid (true), initialize a fixed background fluid (background), or disable the fluid entirely (false).... (default = true)

Other ideas for a parameter name: fluid, status, integrate, evolve....

Or we could possibly fold the switch into existing parameters iso_sound_speed and gamma if we want to avoid adding another parameter.

Thoughts?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.