<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Britton,<div><br></div><div>I need to implement Grackle into ART-NMSU, so I would need:</div><div><br></div><div>+fortran support</div><div>+simpler data structure</div><div> </div><div>I mostly agree with Romain that the current data structure is too heavy:</div><div><br></div><div><br></div><div><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; "><blockquote type="cite">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</blockquote></div></blockquote><div><br></div>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.</div><div>This function is going to be called many times, so I would suggest a minimalistic approach that does the job. </div><div>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.</div><div> </div><div>best</div><div><br></div><div>Daniel</div><div><br><div><div>On Mar 21, 2014, at 6:00 PM, Britton Smith wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">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!<div><br></div><div>Other groups, what are your experiences/needs?</div><div><br></div>
<div>Britton</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 21, 2014 at 4:30 PM, Sam Leitner <span dir="ltr"><<a href="mailto:sam.leitner@gmail.com" target="_blank">sam.leitner@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Nick, that is not correct, my ART implementation uses the grackle solver. We can discuss it in the PR that I issued.</div>
<div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 21, 2014 at 12:23 PM, Nick Gnedin <span dir="ltr"><<a href="mailto:gnedin@fnal.gov" target="_blank">gnedin@fnal.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
At least with ART, the implementation is not what it is supposed to be.<br>
It actually uses ART sub-cycling solver, and only extracts the cooling<br>
rate from Grackle. I thought the plan was for everyone to use<br>
solve_chemistry.<br>
<br>
That's why it is important to converge on the API first.<br>
<div><br>
<br>
On 03/21/2014 11:14 AM, Britton Smith wrote:<br>
> Hi all,<br>
><br>
> This discussion seems to have ground to a halt, so I'll see if I can get<br>
> it going again.<br>
><br>
> It looks like the proposed API is pretty similar to what already exists,<br>
> with mostly cosmetic changes related to what data the user is required<br>
> to carry around. Since we have heard from so few regarding a new API,<br>
> it doesn't seem that many people really want it. Perhaps we should<br>
> establish what groups have completed the Grackle implementation, and<br>
> then we can focus on what the remaining groups need in order to catch<br>
> up. I heard a wise man once say, "You can't always get what you want,<br>
> but if you try sometimes, well you might find you get what you need."<br>
><br>
> We've heard from Ken Nagamine and Junhwan Choi on behalf of the Gadget<br>
> group. I have done Enzo, and to be clear, the Grackle is slightly<br>
> different from what is built in to Enzo, so Enzo now explicitly supports<br>
> Grackle. Sam Leitner has told me that ART is now finished. Are there<br>
> any other groups out there that can report in?<br>
><br>
</div>> So, it sounds to me that one thing that is /needed/ is a clear path to<br>
<div>> implementing the Grackle into a purely fortran code, like Ramses. Is<br>
> that correct? If so, let's talk about how best that can be achieved.<br>
><br>
> To the other groups out there that have not yet finished the<br>
> implementation process, what are the things that you need to get this done?<br>
><br>
> Britton<br>
><br>
> On Thu, Mar 20, 2014 at 3:07 PM, Junhwan Choi (최준환)<br>
</div><div><div>> <<a href="mailto:choi.junhwan@gmail.com" target="_blank">choi.junhwan@gmail.com</a> <mailto:<a href="mailto:choi.junhwan@gmail.com" target="_blank">choi.junhwan@gmail.com</a>>> wrote:<br>
><br>
> Hi Romain,<br>
><br>
> For me, it took about two weeks to make it works.<br>
> But, I spend considerable time to find a way to pass the system unit<br>
> to grackle properly.<br>
> There are a few outstanding issues on this adjustment.<br>
><br>
> 1. Grackle use C++ and wrap the FORTRAN cooling routine. It is not<br>
> trivial to call this C++ wrapped the FORTRAN but there is example in<br>
> the grackle example directory.<br>
><br>
> 2. In the gadget case, I pass one particle by one particle to the<br>
> grackle in order to calculate the cooling. The reason is that the<br>
> gadget cooling and star formation routine is based on particle by<br>
> particle. Indeed, it is least efficient way but so far I have not<br>
> experienced significant slow down.<br>
> [If I use tabulated H and He cooling rates from grackle, it takes<br>
> almost the same time with the original gadget cooling.]<br>
><br>
><br>
> 3. For unit adjustment, we can set as follow:<br>
> my_units.comoving_coordinates = 0;<br>
> my_units.density_units = udensity;<br>
> my_units.length_units = ulength;<br>
> my_units.time_units = utime;<br>
> my_units.a_units = 1.0;<br>
> [udensity, ulength, and utime is the conversion factor from system<br>
> physical units to cgs.]<br>
> In this case, you can pass the density, internal energy, and chemistry<br>
> value in system physical unit.<br>
><br>
> Besides these issues, the incorporating Grackle should not be very<br>
> difficult.<br>
><br>
> Best,<br>
> Junhwan<br>
><br>
><br>
><br>
><br>
><br>
> On Thu, Mar 20, 2014 at 2:35 AM, Romain Teyssier<br>
</div></div><div>> <<a href="mailto:romain.teyssier@gmail.com" target="_blank">romain.teyssier@gmail.com</a> <mailto:<a href="mailto:romain.teyssier@gmail.com" target="_blank">romain.teyssier@gmail.com</a>>> wrote:<br>
> > That's great.<br>
> > A very important question: how long did it take him to succeed ?<br>
> > Since in my opinion, many "adjustments" need to be done, I would<br>
> be curious to<br>
> > have an estimate on the time required that have this working.<br>
> ><br>
> > Cheers,<br>
> > Romain<br>
> ><br>
> > On 20 Mar 2014, at 00:33, Ken Nagamine <<a href="mailto:kn@physics.unlv.edu" target="_blank">kn@physics.unlv.edu</a><br>
</div><div>> <mailto:<a href="mailto:kn@physics.unlv.edu" target="_blank">kn@physics.unlv.edu</a>>> wrote:<br>
> ><br>
> >> Dear all,<br>
> >><br>
> >> Let me just mention that, on the SPH side, Junhwan Choi has<br>
> already succeeded in<br>
> >> implementing the Grackle package into Gadget3-UNLV version.<br>
> >> We still need to do more checks, but at least the phase diagram<br>
> >> looks reasonable compared to the previous TREECOOL table<br>
> implementation of original Gadget.<br>
> >> Junhwan can explain the details of his implementation method if<br>
> it can be of help for this discussion.<br>
> >><br>
> >> cheers,<br>
> >> Ken<br>
> >><br>
> >><br>
> >> On Mar 20, 2014, at 6:44 AM, Romain Teyssier wrote:<br>
> >><br>
> >>><br>
> >>> On 19 Mar 2014, at 22:35, Matthew Turk <<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a><br>
</div><div>> <mailto:<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>>> wrote:<br>
> >>><br>
> >>>> On Wed, Mar 19, 2014 at 5:26 PM, Romain Teyssier<br>
</div>> >>>> <<a href="mailto:romain.teyssier@gmail.com" target="_blank">romain.teyssier@gmail.com</a> <mailto:<a href="mailto:romain.teyssier@gmail.com" target="_blank">romain.teyssier@gmail.com</a>>><br>
<div><div>> wrote:<br>
> >>>>> 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<br>
> *internal_energy, OK<br>
> >>>>> gr_float *x_velocity, gr_float *y_velocity,<br>
> gr_float *z_velocity, ???<br>
> >>>>> gr_float *HI_density, gr_float<br>
> *HII_density, gr_float *HM_density, too much<br>
> >>>>> gr_float *HeI_density, gr_float<br>
> *HeII_density, gr_float *HeIII_density, too much<br>
> >>>>> gr_float *H2I_density, gr_float<br>
> *H2II_density, too much<br>
> >>>>> gr_float *DI_density, gr_float<br>
> *DII_density, gr_float *HDI_density, too much<br>
> >>>>> gr_float *e_density, gr_float<br>
> *metal_density); OK<br>
> >>>>><br>
> >>>>> What are the *grid related variables ?<br>
> >>>><br>
> >>>> Good question! These, like the code units variables, are<br>
> 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<br>
> were<br>
> >>>> included in (2+2*NGZ, 2+2*NGZ, 2+2*NGZ) blocks and one didn't<br>
> want to<br>
> >>>> spend time solving the ghost zones, they can be masked out.<br>
> 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<br>
> 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<br>
> beam, this would be 1.<br>
> >>>><br>
> >>>> While these typically are better for block or patch based<br>
> solvers, I<br>
> >>>> think that the primary goal -- *minimizing* the overhead to<br>
> using a<br>
> >>>> new code -- is met with them.<br>
> >>><br>
> >>> Well I clearly disagree.<br>
> >>> It is brain damaging to say the least.<br>
> >>><br>
> >>>><br>
> >>>> As I mentioned in our previous email, the velocities are<br>
> supplied for<br>
> >>>> the Sobolev approximation. You can see the full discussion on the<br>
> >>>> public Grackle mailing list here:<br>
> >>>><br>
> >>>><br>
> <a href="https://groups.google.com/forum/#!searchin/grackle-cooling-users/velocity/grackle-cooling-users/Dr77TM2te9g/225RNzoZADEJ" target="_blank">https://groups.google.com/forum/#!searchin/grackle-cooling-users/velocity/grackle-cooling-users/Dr77TM2te9g/225RNzoZADEJ</a><br>
> >>>><br>
> >>>>><br>
> >>>>> If chemistry_data is an external variable, this is a pain<br>
> because this variable need to be declared in the main code.<br>
> >>>>> Same thing for code_units.<br>
> >>>><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>
> >>><br>
> >>> Well I think this should be completely hidden to the user.<br>
> >>> This is a very substantial difference.<br>
> >>><br>
> >>>> Code units, if you want to convert to CGS, will just be 1.0<br>
> for all of<br>
> >>>> them, which can be constant.<br>
> >>>><br>
> >>><br>
> >>> Yes but you still have to create a code_unit type, and set the<br>
> variable to 1.<br>
> >>> Unless you change the calling sequence.<br>
> >>><br>
> >>>>> This is all too ENZO specifics.<br>
> >>>><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<br>
> it's<br>
> >>>> rather intuitive to think of the 3D dataset as a base starting<br>
> point<br>
> >>>> and then reducing overhead by supplying 1-dimensional arrays.<br>
> >>>><br>
> >>><br>
> >>> For a purely local process like cooling and chemistry, the<br>
> natural data type is 1D.<br>
> >>> Cells, particles and what not, could then be sent as a 1D array<br>
> to the chemistry solver.<br>
> >>> 3D structures are relevant only for patch based codes.<br>
> >>><br>
> >>><br>
> >>>> -Matt<br>
> >>>><br>
> >>>>><br>
> >>>>> Romain<br>
> >>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>> On 19 Mar 2014, at 22:08, Matthew Turk <<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a><br>
</div></div><div>> <mailto:<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>>> wrote:<br>
> >>>>><br>
> >>>>>> Hi all,<br>
> >>>>>><br>
> >>>>>> On Wed, Mar 19, 2014 at 4:58 PM, Romain Teyssier<br>
> >>>>>> <<a href="mailto:romain.teyssier@gmail.com" target="_blank">romain.teyssier@gmail.com</a><br>
</div><div><div>> <mailto:<a href="mailto:romain.teyssier@gmail.com" target="_blank">romain.teyssier@gmail.com</a>>> wrote:<br>
> >>>>>>><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<br>
> passing the required variables.<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>>> grackle_init_run()<br>
> >>>>>>>> called once per simulation<br>
> >>>>>>>><br>
> >>>>>>><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<br>
> ionisation state<br>
> >>>>>>><br>
> >>>>>>>> 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>
> >>>>>>><br>
> >>>>>>> In principle at this stage, only aexp is required for cosmo<br>
> runs.<br>
> >>>>>>> For non cosmo runs, the cooling tables do not need to be<br>
> modified.<br>
> >>>>>>><br>
> >>>>>>>><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<br>
> energy.<br>
> >>>>>>>> Input gas properties may be required to have specific<br>
> 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>
> >>>>>>><br>
> >>>>>>> I would rather give the possibility of passing an array of<br>
> cell.<br>
> >>>>>>> Users could also set the array size to 1 to deal with cells<br>
> one by one.<br>
> >>>>>>> The required information could be<br>
> >>>>>>> nH, T or Tovermu or specific energy, metallicity in some<br>
> 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<br>
> output variables.<br>
> >>>>>>><br>
> >>>>>>> These 3 routines are the only one that the user should care<br>
> about.<br>
> >>>>>>><br>
> >>>>>><br>
> >>>>>> This is awfully similar to the existing API:<br>
> >>>>>><br>
> >>>>>><br>
> <a href="https://bitbucket.org/brittonsmith/grackle/src/642cd133535a2dd3c57626b768c7c8c107096ac7/src/clib/grackle.h?at=default" target="_blank">https://bitbucket.org/brittonsmith/grackle/src/642cd133535a2dd3c57626b768c7c8c107096ac7/src/clib/grackle.h?at=default</a><br>
> >>>>>><br>
> >>>>>> The only necessary functions, according to<br>
> >>>>>> <a href="http://grackle.readthedocs.org/en/latest/Integration.html" target="_blank">http://grackle.readthedocs.org/en/latest/Integration.html</a> , 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>
> >>>>>><br>
> <a href="https://bitbucket.org/brittonsmith/grackle/src/642cd133535a2dd3c57626b768c7c8c107096ac7/src/example/example.C?at=default" target="_blank">https://bitbucket.org/brittonsmith/grackle/src/642cd133535a2dd3c57626b768c7c8c107096ac7/src/example/example.C?at=default</a><br>
> >>>>>><br>
> >>>>>> those are the only *functional* routines. Everything else is to<br>
> >>>>>> provide additional information, *not* to actually do any<br>
> computation.<br>
> >>>>>> I think that we have actually met these standards. All of<br>
> the units<br>
> >>>>>> are provided so as the *avoid* any boilerplate -- but if you<br>
> 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>
> >>>>>><br>
> <a href="https://bitbucket.org/brittonsmith/grackle/src/642cd133535a2dd3c57626b768c7c8c107096ac7/src/example/table_example.C?at=default" target="_blank">https://bitbucket.org/brittonsmith/grackle/src/642cd133535a2dd3c57626b768c7c8c107096ac7/src/example/table_example.C?at=default</a><br>
> >>>>>><br>
> >>>>>> it's even simpler. The only *active* routine is called on<br>
> line 120,<br>
> >>>>>> "solve_chemistry". I am genuinely being earnest when I ask,<br>
> from the<br>
> >>>>>> .h file linked above, which arguments to the functions would<br>
> you like<br>
> >>>>>> to see removed? I've included the full function signatures<br>
> 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<br>
> 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<br>
> *z_velocity,<br>
> >>>>>> gr_float *HI_density, gr_float *HII_density, gr_float<br>
> *HM_density,<br>
> >>>>>> gr_float *HeI_density, gr_float *HeII_density, gr_float<br>
> *HeIII_density,<br>
> >>>>>> gr_float *H2I_density, gr_float *H2II_density,<br>
> >>>>>> gr_float *DI_density, gr_float *DII_density, gr_float<br>
> *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>
> >>>>>>> Cheers,<br>
> >>>>>>> Romain<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>>> The API can also define its own data types with natutal<br>
> conversion from<br>
> >>>>>>>> standard types, for example the following code should be<br>
> 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<br>
> 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<br>
> library and<br>
> >>>>>>>> provides a proper Linus-style installer (that will handle<br>
> all HDF5 and<br>
> >>>>>>>> other dependencies), then it should be trivial to<br>
> integrate it in any code.<br>
> >>>>>>>><br>
> >>>>>>>> Nick<br>
> >>>>>>>><br>
> >>>>>>>> To unsubscribe from this group and stop receiving emails<br>
> from it, send an email to <a href="mailto:santacruzgalaxy-list%2Bunsubscribe@ucsc.edu" target="_blank">santacruzgalaxy-list+unsubscribe@ucsc.edu</a><br>
</div></div>> <mailto:<a href="mailto:santacruzgalaxy-list%252Bunsubscribe@ucsc.edu" target="_blank">santacruzgalaxy-list%2Bunsubscribe@ucsc.edu</a>>.<br>
<div>> >>>>>>>> _______________________________________________<br>
> >>>>>>>> santacruzgalaxy-list mailing list<br>
> >>>>>>>> <a href="mailto:santacruzgalaxy-list@ucsc.edu" target="_blank">santacruzgalaxy-list@ucsc.edu</a><br>
</div>> <mailto:<a href="mailto:santacruzgalaxy-list@ucsc.edu" target="_blank">santacruzgalaxy-list@ucsc.edu</a>><br>
<div>> >>>>>>>> <a href="https://lists.ucsc.edu/mailman/listinfo/santacruzgalaxy-list" target="_blank">https://lists.ucsc.edu/mailman/listinfo/santacruzgalaxy-list</a><br>
> >>>>>>><br>
> >>>>>>> --<br>
> >>>>>>> You received this message because you are subscribed to the<br>
> Google Groups "Grackle Cooling Library Users" group.<br>
> >>>>>>> To unsubscribe from this group and stop receiving emails<br>
> from it, send an email to<br>
> <a href="mailto:grackle-cooling-users%2Bunsubscribe@googlegroups.com" target="_blank">grackle-cooling-users+unsubscribe@googlegroups.com</a><br>
</div>> <mailto:<a href="mailto:grackle-cooling-users%252Bunsubscribe@googlegroups.com" target="_blank">grackle-cooling-users%2Bunsubscribe@googlegroups.com</a>>.<br>
<div>> >>>>>>> For more options, visit <a href="https://groups.google.com/d/optout" target="_blank">https://groups.google.com/d/optout</a>.<br>
> >>><br>
> >>><br>
> >>> To unsubscribe from this group and stop receiving emails from<br>
> it, send an email to <a href="mailto:santacruzgalaxy-list%2Bunsubscribe@ucsc.edu" target="_blank">santacruzgalaxy-list+unsubscribe@ucsc.edu</a><br>
</div>> <mailto:<a href="mailto:santacruzgalaxy-list%252Bunsubscribe@ucsc.edu" target="_blank">santacruzgalaxy-list%2Bunsubscribe@ucsc.edu</a>>.<br>
<div>> >>> _______________________________________________<br>
> >>> santacruzgalaxy-list mailing list<br>
> >>> <a href="mailto:santacruzgalaxy-list@ucsc.edu" target="_blank">santacruzgalaxy-list@ucsc.edu</a><br>
</div>> <mailto:<a href="mailto:santacruzgalaxy-list@ucsc.edu" target="_blank">santacruzgalaxy-list@ucsc.edu</a>><br>
<div>> >>> <a href="https://lists.ucsc.edu/mailman/listinfo/santacruzgalaxy-list" target="_blank">https://lists.ucsc.edu/mailman/listinfo/santacruzgalaxy-list</a><br>
> >><br>
> ><br>
> > --<br>
> > You received this message because you are subscribed to the<br>
> Google Groups "Grackle Cooling Library Users" group.<br>
> > To unsubscribe from this group and stop receiving emails from it,<br>
> send an email to <a href="mailto:grackle-cooling-users%2Bunsubscribe@googlegroups.com" target="_blank">grackle-cooling-users+unsubscribe@googlegroups.com</a><br>
</div>> <mailto:<a href="mailto:grackle-cooling-users%252Bunsubscribe@googlegroups.com" target="_blank">grackle-cooling-users%2Bunsubscribe@googlegroups.com</a>>.<br>
<div>> > For more options, visit <a href="https://groups.google.com/d/optout" target="_blank">https://groups.google.com/d/optout</a>.<br>
><br>
> --<br>
> You received this message because you are subscribed to the Google<br>
> Groups "Grackle Cooling Library Users" group.<br>
> To unsubscribe from this group and stop receiving emails from it,<br>
> send an email to <a href="mailto:grackle-cooling-users%2Bunsubscribe@googlegroups.com" target="_blank">grackle-cooling-users+unsubscribe@googlegroups.com</a><br>
</div>> <mailto:<a href="mailto:grackle-cooling-users%252Bunsubscribe@googlegroups.com" target="_blank">grackle-cooling-users%2Bunsubscribe@googlegroups.com</a>>.<br>
<div>> For more options, visit <a href="https://groups.google.com/d/optout" target="_blank">https://groups.google.com/d/optout</a>.<br>
><br>
><br>
> To unsubscribe from this group and stop receiving emails from it, send<br>
> an email to <a href="mailto:santacruzgalaxy-list%2Bunsubscribe@ucsc.edu" target="_blank">santacruzgalaxy-list+unsubscribe@ucsc.edu</a><br>
</div>> <mailto:<a href="mailto:santacruzgalaxy-list%2Bunsubscribe@ucsc.edu" target="_blank">santacruzgalaxy-list+unsubscribe@ucsc.edu</a>>.<br>
<div><div>_______________________________________________<br>
santacruzgalaxy-list mailing list<br>
<a href="mailto:santacruzgalaxy-list@ucsc.edu" target="_blank">santacruzgalaxy-list@ucsc.edu</a><br>
<a href="https://lists.ucsc.edu/mailman/listinfo/santacruzgalaxy-list" target="_blank">https://lists.ucsc.edu/mailman/listinfo/santacruzgalaxy-list</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
santacruzgalaxy-list mailing list<br>
<a href="mailto:santacruzgalaxy-list@ucsc.edu">santacruzgalaxy-list@ucsc.edu</a><br>
<a href="https://lists.ucsc.edu/mailman/listinfo/santacruzgalaxy-list" target="_blank">https://lists.ucsc.edu/mailman/listinfo/santacruzgalaxy-list</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>santacruzgalaxy-list mailing list<br><a href="mailto:santacruzgalaxy-list@ucsc.edu">santacruzgalaxy-list@ucsc.edu</a><br>https://lists.ucsc.edu/mailman/listinfo/santacruzgalaxy-list<br></blockquote></div><br></div></body></html>