[santacruzgalaxy-list] Grackle proposal
Sam Leitner
sam.leitner at gmail.com
Fri Mar 21 11:51:20 PDT 2014
Hi All,
While testing GRACKLE, I generally found differences from ART's default
(equilibrium) cooling module to be small (10% level), and probably
negligible compared to other physics in the code. I wonder if this is the
case for ART-I, RAMSES and GASOLINE as well. In that case, maybe this push
to get *exactly* the same cooling function is mostly just an aesthetic
choice that is beginning to hold the whole project back.
As such, perhaps we should first check whether differences are
large/non-negligible in the remaining codes, and, if they are not, continue
on to the science. In particular, I would be happy to output the cooling
functions at several redshifts, densities, and metallicities for those
remaining groups to check their modules against. We could also check that
the integrators produce similar results by following through on the
single-zone cooling test already proposed by the Isolated Disk group
leaders.
I realize this is probably an unpopular suggestion -- both for people who
have already done a ton of work to make GRACKLE usable/work, and to those
who just want a simple API -- but I thought I'd throw it out there as a
possible compromise that could save everyone from some work and further
conflict.
Sam
On Fri, Mar 21, 2014 at 2:22 PM, Romain Teyssier
<romain.teyssier at gmail.com>wrote:
> It would be awesome to have instead something like that:
>
> int solve_chemistry(float dt_value,
> float *density, float *internal_energy,
> float *metal_density);
>
>
> Does it mean that the input internal energy is modified on exit ?
>
> Romain
>
>
>
>
>
> Cheers,
>
> Nathan
>
>
> On Fri, Mar 21, 2014 at 10:47 AM, Daniel Ceverino <daniel.ceverino at uam.es>wrote:
>
>> Hi Britton,
>>
>> I need to implement Grackle into ART-NMSU, so I would need:
>>
>> +fortran support
>> +simpler data structure
>>
>> I mostly agree with Romain that the current data structure is too heavy:
>>
>>
>> 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
>>
>>
>> For equilibrium cooling, many of these grids are not necessary. If we
>> agree that solve_chemistry is called once per each resolution element, I
>> think we need to simply it and get rid of the 3D grids.
>> This function is going to be called many times, so I would suggest a
>> minimalistic approach that does the job.
>> We can add more layers of complexity later, like the sobolev aprox, which
>> needs the velocity gradients, right?, but first we need to agree on a
>> minimum API.
>>
>> best
>>
>> Daniel
>>
>> On Mar 21, 2014, at 6:00 PM, Britton Smith wrote:
>>
>> Sam, that is great news that no alterations need to be made for Grackle
>> to work with ART. Thanks for your hard work on this!
>>
>> Other groups, what are your experiences/needs?
>>
>> Britton
>>
>>
>> On Fri, Mar 21, 2014 at 4:30 PM, Sam Leitner <sam.leitner at gmail.com>wrote:
>>
>>> Nick, that is not correct, my ART implementation uses the grackle
>>> solver. We can discuss it in the PR that I issued.
>>>
>>>
>>> On Fri, Mar 21, 2014 at 12:23 PM, Nick Gnedin <gnedin at fnal.gov> wrote:
>>>
>>>>
>>>> At least with ART, the implementation is not what it is supposed to be.
>>>> It actually uses ART sub-cycling solver, and only extracts the cooling
>>>> rate from Grackle. I thought the plan was for everyone to use
>>>> solve_chemistry.
>>>>
>>>> That's why it is important to converge on the API first.
>>>>
>>>>
>>>> On 03/21/2014 11:14 AM, Britton Smith wrote:
>>>> > Hi all,
>>>> >
>>>> > This discussion seems to have ground to a halt, so I'll see if I can
>>>> get
>>>> > it going again.
>>>> >
>>>> > It looks like the proposed API is pretty similar to what already
>>>> exists,
>>>> > with mostly cosmetic changes related to what data the user is required
>>>> > to carry around. Since we have heard from so few regarding a new API,
>>>> > it doesn't seem that many people really want it. Perhaps we should
>>>> > establish what groups have completed the Grackle implementation, and
>>>> > then we can focus on what the remaining groups need in order to catch
>>>> > up. I heard a wise man once say, "You can't always get what you want,
>>>> > but if you try sometimes, well you might find you get what you need."
>>>> >
>>>> > We've heard from Ken Nagamine and Junhwan Choi on behalf of the Gadget
>>>> > group. I have done Enzo, and to be clear, the Grackle is slightly
>>>> > different from what is built in to Enzo, so Enzo now explicitly
>>>> supports
>>>> > Grackle. Sam Leitner has told me that ART is now finished. Are there
>>>> > any other groups out there that can report in?
>>>> >
>>>> > So, it sounds to me that one thing that is /needed/ is a clear path to
>>>> > implementing the Grackle into a purely fortran code, like Ramses. Is
>>>> > that correct? If so, let's talk about how best that can be achieved.
>>>> >
>>>> > To the other groups out there that have not yet finished the
>>>> > implementation process, what are the things that you need to get this
>>>> done?
>>>> >
>>>> > Britton
>>>> >
>>>> > On Thu, Mar 20, 2014 at 3:07 PM, Junhwan Choi (최준환)
>>>> > <choi.junhwan at gmail.com <mailto:choi.junhwan at gmail.com>> wrote:
>>>> >
>>>> > Hi Romain,
>>>> >
>>>> > For me, it took about two weeks to make it works.
>>>> > But, I spend considerable time to find a way to pass the system
>>>> unit
>>>> > to grackle properly.
>>>> > There are a few outstanding issues on this adjustment.
>>>> >
>>>> > 1. Grackle use C++ and wrap the FORTRAN cooling routine. It is
>>>> not
>>>> > trivial to call this C++ wrapped the FORTRAN but there is example
>>>> in
>>>> > the grackle example directory.
>>>> >
>>>> > 2. In the gadget case, I pass one particle by one particle to the
>>>> > grackle in order to calculate the cooling. The reason is that the
>>>> > gadget cooling and star formation routine is based on particle by
>>>> > particle. Indeed, it is least efficient way but so far I have not
>>>> > experienced significant slow down.
>>>> > [If I use tabulated H and He cooling rates from grackle, it takes
>>>> > almost the same time with the original gadget cooling.]
>>>> >
>>>> >
>>>> > 3. For unit adjustment, we can set as follow:
>>>> > my_units.comoving_coordinates = 0;
>>>> > my_units.density_units = udensity;
>>>> > my_units.length_units = ulength;
>>>> > my_units.time_units = utime;
>>>> > my_units.a_units = 1.0;
>>>> > [udensity, ulength, and utime is the conversion factor from system
>>>> > physical units to cgs.]
>>>> > In this case, you can pass the density, internal energy, and
>>>> chemistry
>>>> > value in system physical unit.
>>>> >
>>>> > Besides these issues, the incorporating Grackle should not be very
>>>> > difficult.
>>>> >
>>>> > Best,
>>>> > Junhwan
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Thu, Mar 20, 2014 at 2:35 AM, Romain Teyssier
>>>> > <romain.teyssier at gmail.com <mailto:romain.teyssier at gmail.com>>
>>>> wrote:
>>>> > > That's great.
>>>> > > A very important question: how long did it take him to succeed
>>>> ?
>>>> > > Since in my opinion, many "adjustments" need to be done, I
>>>> would
>>>> > be curious to
>>>> > > have an estimate on the time required that have this working.
>>>> > >
>>>> > > Cheers,
>>>> > > Romain
>>>> > >
>>>> > > On 20 Mar 2014, at 00:33, Ken Nagamine <kn at physics.unlv.edu
>>>> > <mailto:kn at physics.unlv.edu>> wrote:
>>>> > >
>>>> > >> Dear all,
>>>> > >>
>>>> > >> Let me just mention that, on the SPH side, Junhwan Choi has
>>>> > already succeeded in
>>>> > >> implementing the Grackle package into Gadget3-UNLV version.
>>>> > >> We still need to do more checks, but at least the phase
>>>> diagram
>>>> > >> looks reasonable compared to the previous TREECOOL table
>>>> > implementation of original Gadget.
>>>> > >> Junhwan can explain the details of his implementation method
>>>> if
>>>> > it can be of help for this discussion.
>>>> > >>
>>>> > >> cheers,
>>>> > >> Ken
>>>> > >>
>>>> > >>
>>>> > >> On Mar 20, 2014, at 6:44 AM, Romain Teyssier wrote:
>>>> > >>
>>>> > >>>
>>>> > >>> On 19 Mar 2014, at 22:35, Matthew Turk <
>>>> matthewturk at gmail.com
>>>> > <mailto:matthewturk at gmail.com>> wrote:
>>>> > >>>
>>>> > >>>> On Wed, Mar 19, 2014 at 5:26 PM, Romain Teyssier
>>>> > >>>> <romain.teyssier at gmail.com <mailto:
>>>> romain.teyssier at gmail.com>>
>>>> > wrote:
>>>> > >>>>> 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 ?
>>>> > >>>>
>>>> > >>>> Good question! These, like the code units variables, are
>>>> > designed to
>>>> > >>>> minimize the overhead of any simulation that wants to put
>>>> its code
>>>> > >>>> into it. For instance, if one had a patch/block-based code
>>>> (like
>>>> > >>>> Enzo, FLASH, Nyx, etc) or an Octree code where the 2x2x2
>>>> zones
>>>> > were
>>>> > >>>> included in (2+2*NGZ, 2+2*NGZ, 2+2*NGZ) blocks and one
>>>> didn't
>>>> > want to
>>>> > >>>> spend time solving the ghost zones, they can be masked out.
>>>> > These are
>>>> > >>>> the variables:
>>>> > >>>>
>>>> > >>>> grid_start => array of size (grid_rank) indicating the
>>>> indices to
>>>> > >>>> start at in each rank of dimensionality
>>>> > >>>> grid_end => array of size (grid_rank) indicating the indices
>>>> > to *end*
>>>> > >>>> at in each rank of dimensionality
>>>> > >>>> grid_dimension => size of the block of data in each
>>>> dimension
>>>> > >>>> grid_rank => dimensionality; if you're supplying a pencil
>>>> > beam, this would be 1.
>>>> > >>>>
>>>> > >>>> While these typically are better for block or patch based
>>>> > solvers, I
>>>> > >>>> think that the primary goal -- *minimizing* the overhead to
>>>> > using a
>>>> > >>>> new code -- is met with them.
>>>> > >>>
>>>> > >>> Well I clearly disagree.
>>>> > >>> It is brain damaging to say the least.
>>>> > >>>
>>>> > >>>>
>>>> > >>>> As I mentioned in our previous email, the velocities are
>>>> > supplied for
>>>> > >>>> the Sobolev approximation. You can see the full discussion
>>>> on the
>>>> > >>>> public Grackle mailing list here:
>>>> > >>>>
>>>> > >>>>
>>>> >
>>>> https://groups.google.com/forum/#!searchin/grackle-cooling-users/velocity/grackle-cooling-users/Dr77TM2te9g/225RNzoZADEJ
>>>> > >>>>
>>>> > >>>>>
>>>> > >>>>> 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.
>>>> > >>>>
>>>> > >>>> The alternative is that it be a global defined in a
>>>> different
>>>> > >>>> namespace, loading in by the dlloader at runtime. Not sure
>>>> that's
>>>> > >>>> substantially different.
>>>> > >>>>
>>>> > >>>
>>>> > >>> Well I think this should be completely hidden to the user.
>>>> > >>> This is a very substantial difference.
>>>> > >>>
>>>> > >>>> Code units, if you want to convert to CGS, will just be 1.0
>>>> > for all of
>>>> > >>>> them, which can be constant.
>>>> > >>>>
>>>> > >>>
>>>> > >>> Yes but you still have to create a code_unit type, and set
>>>> the
>>>> > variable to 1.
>>>> > >>> Unless you change the calling sequence.
>>>> > >>>
>>>> > >>>>> This is all too ENZO specifics.
>>>> > >>>>
>>>> > >>>> I'm not sure I believe that argument. Perhaps the names of
>>>> the
>>>> > >>>> variables share too much with Enzo naming schemes, but I
>>>> think
>>>> > it's
>>>> > >>>> rather intuitive to think of the 3D dataset as a base
>>>> starting
>>>> > point
>>>> > >>>> and then reducing overhead by supplying 1-dimensional
>>>> arrays.
>>>> > >>>>
>>>> > >>>
>>>> > >>> For a purely local process like cooling and chemistry, the
>>>> > natural data type is 1D.
>>>> > >>> Cells, particles and what not, could then be sent as a 1D
>>>> array
>>>> > to the chemistry solver.
>>>> > >>> 3D structures are relevant only for patch based codes.
>>>> > >>>
>>>> > >>>
>>>> > >>>> -Matt
>>>> > >>>>
>>>> > >>>>>
>>>> > >>>>> Romain
>>>> > >>>>>
>>>> > >>>>>
>>>> > >>>>>
>>>> > >>>>> On 19 Mar 2014, at 22:08, Matthew Turk <
>>>> matthewturk at gmail.com
>>>> > <mailto:matthewturk at gmail.com>> wrote:
>>>> > >>>>>
>>>> > >>>>>> Hi all,
>>>> > >>>>>>
>>>> > >>>>>> On Wed, Mar 19, 2014 at 4:58 PM, Romain Teyssier
>>>> > >>>>>> <romain.teyssier at gmail.com
>>>> > <mailto: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
>>>> > <mailto:santacruzgalaxy-list%2Bunsubscribe at ucsc.edu>.
>>>> > >>>>>>>> _______________________________________________
>>>> > >>>>>>>> santacruzgalaxy-list mailing list
>>>> > >>>>>>>> santacruzgalaxy-list at ucsc.edu
>>>> > <mailto: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
>>>> > <mailto:grackle-cooling-users%2Bunsubscribe 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
>>>> > <mailto:santacruzgalaxy-list%2Bunsubscribe at ucsc.edu>.
>>>> > >>> _______________________________________________
>>>> > >>> santacruzgalaxy-list mailing list
>>>> > >>> santacruzgalaxy-list at ucsc.edu
>>>> > <mailto: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
>>>> > <mailto:grackle-cooling-users%2Bunsubscribe at googlegroups.com>.
>>>> > > For more options, visit https://groups.google.com/d/optout.
>>>> >
>>>> > --
>>>> > 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
>>>> > <mailto:grackle-cooling-users%2Bunsubscribe 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
>>>> > <mailto:santacruzgalaxy-list+unsubscribe at ucsc.edu>.
>>>> _______________________________________________
>>>> santacruzgalaxy-list mailing list
>>>> santacruzgalaxy-list at ucsc.edu
>>>> https://lists.ucsc.edu/mailman/listinfo/santacruzgalaxy-list
>>>>
>>>
>>>
>>> _______________________________________________
>>> santacruzgalaxy-list mailing list
>>> santacruzgalaxy-list at ucsc.edu
>>> https://lists.ucsc.edu/mailman/listinfo/santacruzgalaxy-list
>>>
>>>
>> _______________________________________________
>> santacruzgalaxy-list mailing list
>> santacruzgalaxy-list at ucsc.edu
>> https://lists.ucsc.edu/mailman/listinfo/santacruzgalaxy-list
>>
>>
>>
>> _______________________________________________
>> santacruzgalaxy-list mailing list
>> santacruzgalaxy-list at ucsc.edu
>> https://lists.ucsc.edu/mailman/listinfo/santacruzgalaxy-list
>>
>>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucsc.edu/pipermail/santacruzgalaxy-list/attachments/20140321/22da2565/attachment-0001.html
More information about the santacruzgalaxy-list
mailing list