[santacruzgalaxy-list] Grackle proposal

Wed Mar 19 14:26:05 PDT 2014

Hi Matt,

For example:

int solve_chemistry(chemistry_data &my_chemistry,  ???
		    code_units &my_units, OK set to 1
		    gr_float a_value, gr_float dt_value, why a ?
		    gr_int grid_rank, gr_int *grid_dimension, ????
		    gr_int *grid_start, gr_int *grid_end, ????
		    gr_float *density, gr_float *internal_energy, OK 
		    gr_float *x_velocity, gr_float *y_velocity, gr_float *z_velocity, ???
		    gr_float *HI_density, gr_float *HII_density, gr_float *HM_density, too much
		    gr_float *HeI_density, gr_float *HeII_density, gr_float *HeIII_density, too much
		    gr_float *H2I_density, gr_float *H2II_density, too much
		    gr_float *DI_density, gr_float *DII_density, gr_float *HDI_density, too much
		    gr_float *e_density, gr_float *metal_density); OK

What are the *grid related variables ?

If chemistry_data is an external variable, this is a pain because this variable need to be declared in the main code.
Same thing for code_units.
This is all too ENZO specifics.

Romain

On 19 Mar 2014, at 22:08, Matthew Turk <matthewturk at gmail.com> wrote:

> Hi all,
> 
> On Wed, Mar 19, 2014 at 4:58 PM, Romain Teyssier
> <romain.teyssier at gmail.com> wrote:
>> 
>> I totally agree with the 3 routines that need to be used.
>> Nothing else should be required on the code's side, except passing the required variables.
>> 
>> 
>>> grackle_init_run()
>>>    called once per simulation
>>> 
>> 
>> The parameters that should be passed here are
>> - some cosmological model parameters
>> - UV background model (spectrum, reionization redshift...)
>> - starting redshift to compute the initial temperature and ionisation state
>> 
>>> grackle_init_step(aexp,...)
>>>    called once per each time-step, uses the value of the scale
>>>    factor and other parameters as needed
>> 
>> In principle at this stage, only aexp is required for cosmo runs.
>> For non cosmo runs, the cooling tables do not need to be modified.
>> 
>>> 
>>> grackle_solve_chemistry(dt,den,tem,...)
>>>    called for each resolution element one or more times per one
>>>    global time-step, uses gas properties to update internal energy.
>>>    Input gas properties may be required to have specific units and
>>>    be of specific data type. It should internally sense if it
>>>    runs within an OpenMP construct and support OpenMP
>>>    parallelization.
>>> 
>> 
>> I would rather give the possibility of passing an array of cell.
>> Users could also set the array size to 1 to deal with cells one by one.
>> The required information could be
>> nH, T or Tovermu or specific energy, metallicity in some units, dt_hydro, ncell
>> On output, Delta T or Delta Tovermu or Delta specific energy
>> I suggest we use fixed units (cgs or mks) for all input and output variables.
>> 
>> These 3 routines are the only one that the user should care about.
>> 
> 
> This is awfully similar to the existing API:
> 
> https://bitbucket.org/brittonsmith/grackle/src/642cd133535a2dd3c57626b768c7c8c107096ac7/src/clib/grackle.h?at=default
> 
> The only necessary functions, according to
> http://grackle.readthedocs.org/en/latest/Integration.html , are:
> 
> initialize_chemistry_data
> solve_chemistry or solve_chemistry for tabular data
> 
> Looking at the example (non-equilibrium) executable:
> 
> https://bitbucket.org/brittonsmith/grackle/src/642cd133535a2dd3c57626b768c7c8c107096ac7/src/example/example.C?at=default
> 
> those are the only *functional* routines.  Everything else is to
> provide additional information, *not* to actually do any computation.
> I think that we have actually met these standards.  All of the units
> are provided so as the *avoid* any boilerplate -- but if you want to
> supply in CGS, you can set the input unit conversions to 1.0.
> 
> To compute the equilibrium tables:
> 
> https://bitbucket.org/brittonsmith/grackle/src/642cd133535a2dd3c57626b768c7c8c107096ac7/src/example/table_example.C?at=default
> 
> it's even simpler.  The only *active* routine is called on line 120,
> "solve_chemistry".  I am genuinely being earnest when I ask, from the
> .h file linked above, which arguments to the functions would you like
> to see removed?  I've included the full function signatures below.  If
> you want to get *out* various things, you can utilize the other
> functions -- like the cooling time function and so on.
> 
> -Matt
> 
> int initialize_chemistry_data(chemistry_data &my_chemistry,
>                              code_units &my_units, gr_float a_value);
> 
> int solve_chemistry(chemistry_data &my_chemistry,
>   code_units &my_units,
>   gr_float a_value, gr_float dt_value,
>   gr_int grid_rank, gr_int *grid_dimension,
>   gr_int *grid_start, gr_int *grid_end,
>   gr_float *density, gr_float *internal_energy,
>   gr_float *x_velocity, gr_float *y_velocity, gr_float *z_velocity,
>   gr_float *HI_density, gr_float *HII_density, gr_float *HM_density,
>   gr_float *HeI_density, gr_float *HeII_density, gr_float *HeIII_density,
>   gr_float *H2I_density, gr_float *H2II_density,
>   gr_float *DI_density, gr_float *DII_density, gr_float *HDI_density,
>   gr_float *e_density, gr_float *metal_density);
> 
> int solve_chemistry(chemistry_data &my_chemistry,
>                    code_units &my_units,
>                    gr_float a_value, gr_float dt_value,
>                    gr_int grid_rank, gr_int *grid_dimension,
>                    gr_int *grid_start, gr_int *grid_end,
>                    gr_float *density, gr_float *internal_energy,
>                    gr_float *x_velocity, gr_float *y_velocity,
> gr_float *z_velocity,
>                    gr_float *metal_density);
> 
>> Cheers,
>> Romain
>> 
>> 
>> 
>>> The API can also define its own data types with natutal conversion from
>>> standard types, for example the following code should be valid:
>>> 
>>> float f;
>>> double d;
>>> gr_float gr_f;
>>> 
>>> gr_f = f;
>>> gr_f = d;
>>> 
>>> An analogous API should be provided for F77.
>>> 
>>> Then in a code the API will be implemented as follows:
>>> 
>>> Begin_code
>>> 
>>>    grackle_init_run()
>>> 
>>>    Loop_over_timesteps(aexp)
>>> 
>>>        grackle_init_step(aexp,...)
>>> 
>>> #pragma omp parallel loop
>>>        Loop_over_resolution_elements(elem)
>>>        {
>>>             gr_float dt = code_time_step*time_unit;
>>>             gr_float den = code_density(elem)*den_unit;
>>>             gr_float tem = code_temperature(elem)*tem_unit;
>>>             grackle_solve_chemistry(dt,den,tem,...)
>>>        }
>>> 
>>>    End_loop
>>> 
>>> End_code
>>> 
>>> Let's converge on the API, and then the Grackle team will be able to
>>> write a couple of wrappers that will suit everyone.
>>> 
>>> Given the wrappers, if Grackle is installed as an external library and
>>> provides a proper Linus-style installer (that will handle all HDF5 and
>>> other dependencies), then it should be trivial to integrate it in any code.
>>> 
>>> Nick
>>> 
>>> To unsubscribe from this group and stop receiving emails from it, send an email to santacruzgalaxy-list+unsubscribe at ucsc.edu.
>>> _______________________________________________
>>> santacruzgalaxy-list mailing list
>>> santacruzgalaxy-list at ucsc.edu
>>> https://lists.ucsc.edu/mailman/listinfo/santacruzgalaxy-list
>> 
>> --
>> You received this message because you are subscribed to the Google Groups "Grackle Cooling Library Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to grackle-cooling-users+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

To unsubscribe from this group and stop receiving emails from it, send an email to santacruzgalaxy-list+unsubscribe at ucsc.edu.