<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 19 Mar 2014, at 22:35, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Wed, Mar 19, 2014 at 5:26 PM, Romain Teyssier<br><<a href="mailto:romain.teyssier@gmail.com">romain.teyssier@gmail.com</a>> wrote:<br><blockquote type="cite">Hi Matt,<br><br><br>For example:<br><br>int solve_chemistry(chemistry_data &my_chemistry, ???<br> code_units &my_units, OK set to 1<br> gr_float a_value, gr_float dt_value, why a ?<br> gr_int grid_rank, gr_int *grid_dimension, ????<br> gr_int *grid_start, gr_int *grid_end, ????<br> gr_float *density, gr_float *internal_energy, OK<br> gr_float *x_velocity, gr_float *y_velocity, gr_float *z_velocity, ???<br> gr_float *HI_density, gr_float *HII_density, gr_float *HM_density, too much<br> gr_float *HeI_density, gr_float *HeII_density, gr_float *HeIII_density, too much<br> gr_float *H2I_density, gr_float *H2II_density, too much<br> gr_float *DI_density, gr_float *DII_density, gr_float *HDI_density, too much<br> gr_float *e_density, gr_float *metal_density); OK<br><br>What are the *grid related variables ?<br></blockquote><br>Good question! These, like the code units variables, are designed to<br>minimize the overhead of any simulation that wants to put its code<br>into it. For instance, if one had a patch/block-based code (like<br>Enzo, FLASH, Nyx, etc) or an Octree code where the 2x2x2 zones were<br>included in (2+2*NGZ, 2+2*NGZ, 2+2*NGZ) blocks and one didn't want to<br>spend time solving the ghost zones, they can be masked out. These are<br>the variables:<br><br>grid_start => array of size (grid_rank) indicating the indices to<br>start at in each rank of dimensionality<br>grid_end => array of size (grid_rank) indicating the indices to *end*<br>at in each rank of dimensionality<br>grid_dimension => size of the block of data in each dimension<br>grid_rank => dimensionality; if you're supplying a pencil beam, this would be 1.<br><br>While these typically are better for block or patch based solvers, I<br>think that the primary goal -- *minimizing* the overhead to using a<br>new code -- is met with them.<br></div></blockquote><div><br></div><div>Well I clearly disagree.</div><div>It is brain damaging to say the least.</div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>As I mentioned in our previous email, the velocities are supplied for<br>the Sobolev approximation. You can see the full discussion on the<br>public Grackle mailing list here:<br><br><a href="https://groups.google.com/forum/#!searchin/grackle-cooling-users/velocity/grackle-cooling-users/Dr77TM2te9g/225RNzoZADEJ">https://groups.google.com/forum/#!searchin/grackle-cooling-users/velocity/grackle-cooling-users/Dr77TM2te9g/225RNzoZADEJ</a><br><br><blockquote type="cite"><br>If chemistry_data is an external variable, this is a pain because this variable need to be declared in the main code.<br>Same thing for code_units.<br></blockquote><br>The alternative is that it be a global defined in a different<br>namespace, loading in by the dlloader at runtime. Not sure that's<br>substantially different.<br><br></div></blockquote><div><br></div><div>Well I think this should be completely hidden to the user.</div><div>This is a very substantial difference.</div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Code units, if you want to convert to CGS, will just be 1.0 for all of<br>them, which can be constant.<br><br></div></blockquote><div><br></div><div>Yes but you still have to create a code_unit type, and set the variable to 1.</div><div>Unless you change the calling sequence.</div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite">This is all too ENZO specifics.<br></blockquote><br>I'm not sure I believe that argument. Perhaps the names of the<br>variables share too much with Enzo naming schemes, but I think it's<br>rather intuitive to think of the 3D dataset as a base starting point<br>and then reducing overhead by supplying 1-dimensional arrays.<br><br></div></blockquote><div><br></div><div>For a purely local process like cooling and chemistry, the natural data type is 1D.</div><div>Cells, particles and what not, could then be sent as a 1D array to the chemistry solver.</div><div>3D structures are relevant only for patch based codes.</div><div><br></div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">-Matt<br><br><blockquote type="cite"><br>Romain<br><br><br><br>On 19 Mar 2014, at 22:08, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br><br><blockquote type="cite">Hi all,<br><br>On Wed, Mar 19, 2014 at 4:58 PM, Romain Teyssier<br><<a href="mailto:romain.teyssier@gmail.com">romain.teyssier@gmail.com</a>> wrote:<br><blockquote type="cite"><br>I totally agree with the 3 routines that need to be used.<br>Nothing else should be required on the code's side, except passing the required variables.<br><br><br><blockquote type="cite">grackle_init_run()<br> called once per simulation<br><br></blockquote><br>The parameters that should be passed here are<br>- some cosmological model parameters<br>- UV background model (spectrum, reionization redshift...)<br>- starting redshift to compute the initial temperature and ionisation state<br><br><blockquote type="cite">grackle_init_step(aexp,...)<br> called once per each time-step, uses the value of the scale<br> factor and other parameters as needed<br></blockquote><br>In principle at this stage, only aexp is required for cosmo runs.<br>For non cosmo runs, the cooling tables do not need to be modified.<br><br><blockquote type="cite"><br>grackle_solve_chemistry(dt,den,tem,...)<br> called for each resolution element one or more times per one<br> global time-step, uses gas properties to update internal energy.<br> Input gas properties may be required to have specific units and<br> be of specific data type. It should internally sense if it<br> runs within an OpenMP construct and support OpenMP<br> parallelization.<br><br></blockquote><br>I would rather give the possibility of passing an array of cell.<br>Users could also set the array size to 1 to deal with cells one by one.<br>The required information could be<br>nH, T or Tovermu or specific energy, metallicity in some units, dt_hydro, ncell<br>On output, Delta T or Delta Tovermu or Delta specific energy<br>I suggest we use fixed units (cgs or mks) for all input and output variables.<br><br>These 3 routines are the only one that the user should care about.<br><br></blockquote><br>This is awfully similar to the existing API:<br><br><a href="https://bitbucket.org/brittonsmith/grackle/src/642cd133535a2dd3c57626b768c7c8c107096ac7/src/clib/grackle.h?at=default">https://bitbucket.org/brittonsmith/grackle/src/642cd133535a2dd3c57626b768c7c8c107096ac7/src/clib/grackle.h?at=default</a><br><br>The only necessary functions, according to<br>http://grackle.readthedocs.org/en/latest/Integration.html , are:<br><br>initialize_chemistry_data<br>solve_chemistry or solve_chemistry for tabular data<br><br>Looking at the example (non-equilibrium) executable:<br><br>https://bitbucket.org/brittonsmith/grackle/src/642cd133535a2dd3c57626b768c7c8c107096ac7/src/example/example.C?at=default<br><br>those are the only *functional* routines. Everything else is to<br>provide additional information, *not* to actually do any computation.<br>I think that we have actually met these standards. All of the units<br>are provided so as the *avoid* any boilerplate -- but if you want to<br>supply in CGS, you can set the input unit conversions to 1.0.<br><br>To compute the equilibrium tables:<br><br>https://bitbucket.org/brittonsmith/grackle/src/642cd133535a2dd3c57626b768c7c8c107096ac7/src/example/table_example.C?at=default<br><br>it's even simpler. The only *active* routine is called on line 120,<br>"solve_chemistry". I am genuinely being earnest when I ask, from the<br>.h file linked above, which arguments to the functions would you like<br>to see removed? I've included the full function signatures below. If<br>you want to get *out* various things, you can utilize the other<br>functions -- like the cooling time function and so on.<br><br>-Matt<br><br>int initialize_chemistry_data(chemistry_data &my_chemistry,<br> code_units &my_units, gr_float a_value);<br><br>int solve_chemistry(chemistry_data &my_chemistry,<br> code_units &my_units,<br> gr_float a_value, gr_float dt_value,<br> gr_int grid_rank, gr_int *grid_dimension,<br> gr_int *grid_start, gr_int *grid_end,<br> gr_float *density, gr_float *internal_energy,<br> gr_float *x_velocity, gr_float *y_velocity, gr_float *z_velocity,<br> gr_float *HI_density, gr_float *HII_density, gr_float *HM_density,<br> gr_float *HeI_density, gr_float *HeII_density, gr_float *HeIII_density,<br> gr_float *H2I_density, gr_float *H2II_density,<br> gr_float *DI_density, gr_float *DII_density, gr_float *HDI_density,<br> gr_float *e_density, gr_float *metal_density);<br><br>int solve_chemistry(chemistry_data &my_chemistry,<br> code_units &my_units,<br> gr_float a_value, gr_float dt_value,<br> gr_int grid_rank, gr_int *grid_dimension,<br> gr_int *grid_start, gr_int *grid_end,<br> gr_float *density, gr_float *internal_energy,<br> gr_float *x_velocity, gr_float *y_velocity,<br>gr_float *z_velocity,<br> gr_float *metal_density);<br><br><blockquote type="cite">Cheers,<br>Romain<br><br><br><br><blockquote type="cite">The API can also define its own data types with natutal conversion from<br>standard types, for example the following code should be valid:<br><br>float f;<br>double d;<br>gr_float gr_f;<br><br>gr_f = f;<br>gr_f = d;<br><br>An analogous API should be provided for F77.<br><br>Then in a code the API will be implemented as follows:<br><br>Begin_code<br><br> grackle_init_run()<br><br> Loop_over_timesteps(aexp)<br><br> grackle_init_step(aexp,...)<br><br>#pragma omp parallel loop<br> Loop_over_resolution_elements(elem)<br> {<br> gr_float dt = code_time_step*time_unit;<br> gr_float den = code_density(elem)*den_unit;<br> gr_float tem = code_temperature(elem)*tem_unit;<br> grackle_solve_chemistry(dt,den,tem,...)<br> }<br><br> End_loop<br><br>End_code<br><br>Let's converge on the API, and then the Grackle team will be able to<br>write a couple of wrappers that will suit everyone.<br><br>Given the wrappers, if Grackle is installed as an external library and<br>provides a proper Linus-style installer (that will handle all HDF5 and<br>other dependencies), then it should be trivial to integrate it in any code.<br><br>Nick<br><br>To unsubscribe from this group and stop receiving emails from it, send an email to santacruzgalaxy-list+unsubscribe@ucsc.edu.<br>_______________________________________________<br>santacruzgalaxy-list mailing list<br>santacruzgalaxy-list@ucsc.edu<br>https://lists.ucsc.edu/mailman/listinfo/santacruzgalaxy-list<br></blockquote><br>--<br>You received this message because you are subscribed to the Google Groups "Grackle Cooling Library Users" group.<br>To unsubscribe from this group and stop receiving emails from it, send an email to grackle-cooling-users+unsubscribe@googlegroups.com.<br>For more options, visit https://groups.google.com/d/optout.</blockquote></blockquote></blockquote></div></blockquote></div><br></body></html>
<p></p>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:santacruzgalaxy-list+unsubscribe@ucsc.edu">santacruzgalaxy-list+unsubscribe@ucsc.edu</a>.<br />