switch problem parameters to a script

[zingale]

We should list the problem-specific parameters in a file like we do with the extern parameters (like _parameters), and then parse this at compile time to build the probin module and the namelist read mechanism called from probinit().

This will be cleaner and easier to generalize to the GPUs. We should switch all problems to this system. This is similar to what Maestro currently does. We can build from the infrastructure that exists for extern already.

[zingale]

this is a little more complicated than how we do extern parameters right now, since sometimes we have arrays as problem parameters. So we need to specify the size and how to initialize the array. For arrays
where the size is only known at runtime, we will need to have a mechanism to initialize however many elements exist.

correction: this is not true -- all parameters are scalars.

[zingale]

we should reuse write_probin.py for this. This is currently used by Maestro and for extern problems.

To extend it to the use case for Castro we can either:

• require that parameters are all scalars, and if problems need to initialize multiple values, require that that be done with more parameters

• extend the format of the _parameters file to accept a length and allow for a tuple of values to be specificed as the default.

The other design consideration is whether we want this to be something separate from now we deal with extern, or if they can all be in the same module?

[zingale]

It turns out that there are not array parameters, but rather, the probdata module sometimes has array members simply to allow passing of information betweeb probinit and initdata, and perhaps a few other places. So we need a solution that allows us to automate runtime parameters while also allowing us to maintain a module for passing information between routines. Perhaps the solution to this is to have 2 separate modules?

[maximumcats]

I would have this script create a new module called problem_data, say, and have the existing probdata modules do an unrestricted use of the problem_data module.

[zingale]

as part of this, we should consider eliminating the probin files completely in favor of AMReX's ability to embed namelists in the inputs file

from Weiqun:

in inputs, you would do:

foo = 3.4

&flst1
   nitems = 5,
   s_factors(1,1:2,1) = 2, 3
/

bar = 4

then to read it as a string that Fortran can deal with:

    use amrex_parmparse_module, only : amrex_namelist

    integer :: nitems
    integer :: s_factors(3,3,3)
    !
    real(amrex_real) :: ff2
    !
    character(len=10) :: ff3
    !
    real(amrex_real) :: center

    namelist /flst1/ nitems, s_factors
    namelist /flst2/ ff2
    namelist /flst3/ ff3
    namelist /probin/ center

    s_factors = 0
    read(amrex_namelist, flst1)
    read(amrex_namelist, flst2)
    read(amrex_namelist, flst3)
    read(amrex_namelist, probin)

[zingale]

actually... we don't need to do anything new. We could just have the problems have a _parameters file and then anything defined there gets added to extern_probin_module automagically.