Mailman 3 January 2009 - yt-dev

field_parameters in phase plots
by david collins 18 Jan '09

18 Jan '09

Hi, Matt/everyone-- I'm trying to make a density/magnetic field/ mean velocity dispersion plot, where the velocity is the z (color) axis. I want my dispersion to be V-BulkVelocity, but right now I'm getting BulkVelocity through set_field_paremter, which seems to not be done on the extracted regions inside of the phase plot. Anyone have a good idea how to feed BulkVelocity automatically in to the quantity? d.

2 2

boundedness change
by Matthew Turk 18 Jan '09

18 Jan '09

I (reluctantly?) agree with Britton that there's an error. He's going to fix it, unless somebody speaks now. (Else, holding peace forever is expected.) Forwarded conversation Subject: yt: embarrassing question, gravity ------------------------ From: *david collins* <antpuncher(a)gmail.com> Date: Sat, Jan 17, 2009 at 5:28 PM To: Matthew Turk <matthewturk(a)gmail.com> Hey, Matthew-- I have an embarrassingly dumb question that I'm not going to see until I ask someone. And I swear it made sense to me once. In your _IsBound function, you have pot = 2*G*PointCombine = 2 * G * Sum_i{ Sum_j { m_i * m_j / || r_i - r_j || }} Why the 2 in front? Why isn't there a 1/2 for double counting in the sum? And isn't the virial thm 2*KE < PE? So Now I'm missing an extra 2, so I'm off by 8. Thanks, d. ---------- From: *Matthew Turk* <matthewturk(a)gmail.com> Date: Sat, Jan 17, 2009 at 5:40 PM To: Britton Smith <brittonsmith(a)gmail.com> Begin forwarded message: *From:* "david collins" <antpuncher(a)gmail.com> *Date:* January 17, 2009 5:28:31 PM PST *To:* "Matthew Turk" <matthewturk(a)gmail.com> *Subject:* *yt: embarrassing question, gravity* ---------- From: *Matthew Turk* <matthewturk(a)gmail.com> Date: Sat, Jan 17, 2009 at 5:45 PM To: david collins <antpuncher(a)gmail.com> Cc: Britton Smith <brittonsmith(a)gmail.com> Hey, Britton wrote it so I fwd'd it to him. We don't double count, tho - iteration is n < m inside PointCombine.c. Hopefully Britton can point out more? -Matt ---------- From: *david collins* <antpuncher(a)gmail.com> Date: Sat, Jan 17, 2009 at 5:49 PM To: Matthew Turk <matthewturk(a)gmail.com> > iteration is n < m inside PointCombine.c.] Todja it was dumb-- I fail both reading and programming on that one... XD d. ---------- From: *Britton Smith* <brittonsmith(a)gmail.com> Date: Sat, Jan 17, 2009 at 6:39 PM To: Matthew Turk <matthewturk(a)gmail.com> Cc: david collins <antpuncher(a)gmail.com> After looking at this again, I think the first 2, as in 2 * G * Sum_i{ Sum_j { m_i * m_j / || r_i - r_j || }}, may be an error. As Matt said, the sum is actually i = 0 ... N-1 and j = i+1...N, so there is no need for an additional 0.5. When I had done this originally, I was somewhat uncertain about calculating the boundness of N particles as to whether you should do the full sum or this partial sum mentioned above. I had found the source to some other code that calculates gravitational potential for particles and it had this partial sum with a 2 out front, so I went with that. That, I'm pretty sure now, it not right. The total binding energy is actually the sum over all N * (N - 1) / 2 pairs of cells or particles, which is exactly the sum above without that 2. My impression of the virial theorem is that it applies to the time average of KE and PE. Any body in a stable orbit will satisfy the virial theorem when averaged over the entire orbit. A perfectly circular orbit has 2*KE = PE all the time, but an elliptical orbit will vary in both directions throughout its orbit. So, gravitational boundness for an object requires that KE < PE at all times, but when you do a time average of that object you will find 2 <KE> = <PE>. In conclusion, there should be no problem with respect to the virial theorem, but the first 2 in front of the sum should probably be removed. If you guys agree with this, I will go ahead and remove that 2 from the calculation. Let me know what you guys think. Thanks for pointing this out, Dave. Britton

4 7

Fwd: [Yt-svn] yt-commit r1126 - trunk/yt/lagos
by Britton Smith 17 Jan '09

17 Jan '09

Hi everyone, I made a sizable update to the Clump class, allowing far more flexibility in the type of output you get from the clump finder. In case anyone is interested, here's the commit log. Britton Author: britton Date: Sat Jan 17 12:43:53 2009 New Revision: 1126 URL: http://yt.spacepope.org/changeset/1126 Log: Added clump_info attribute to Clump objects. clump_info is an list of dictionaries, each with two entries: "quantity" and "format". The quantity entry contains a string representing the function to be called to get some Clump quantity or quantities. The format entry contains another string that controls the format that the quantity is to be written out. Both are used with eval statemets by the new Clump info writing method, write_info. The method, write_info, is called by the write_clumps and write_clump_hierarchy routines. This allows the user to add their own quantities to the list to be printed out by write_clumps and write_clump_hierarchy. This is done by the Clump method add_info_item, which takes arguments quantity and format to be added to the clump_info list. After adding the entry to the clump_info list, the method is called for each of the clumps children in a recursive fashion so that all children in the hierarchy have the same clump_info list. The Clump __init__ function now also accepts the keyword, clump_info, so that clump_info traits can be passed down at instantiation. This means that add_info_item can be called either before or after the clump finding is done. If clump objects are instantiated with no entries in clump_info, the method, set_default_clump_info is called to add the standard info items that were printed out by the old writing functions. This means that by running the clump finder the way it has always been run, you will get the same output as before. Check out this method for examples of proper calls to add_info_item. The clump_info list can be cleared with the clear_clump_info method. Clump objects now also contain a method called "pass_down", which allows the user to pass down any sort of command that is to be executed by all clumps in the hierarchy. The argument to pass_down is given as a string to be executed with eval. For example, this allows the user to define clump characteristics for each clump that depend on external data not known before clump finding. One specific example would be a clump info item that is the distance from the center of mass of the master clump. Finally, for backwards compatibility, the original clump writing functions have been kept around as write_old_clumps and write_old_clump_hierarchy. Modified: trunk/yt/lagos/Clump.py Modified: trunk/yt/lagos/Clump.py ============================================================================== --- trunk/yt/lagos/Clump.py (original) +++ trunk/yt/lagos/Clump.py Sat Jan 17 12:43:53 2009 @@ -22,13 +22,13 @@ along with this program. If not, see <http://www.gnu.org/licenses/>. """ - from yt.lagos import * import numpy as na +import copy class Clump(object): children = None - def __init__(self, data, parent, field, cached_fields = None, function=None): + def __init__(self, data, parent, field, cached_fields = None, function=None, clump_info=None): self.parent = parent self.data = data self.field = field @@ -36,6 +36,14 @@ self.max = self.data[field].max() self.cached_fields = cached_fields + # List containing characteristics about clumps that are to be written + # out by the write routines. + if clump_info is None: + self.set_default_clump_info() + else: + # Clump info will act the same if add_info_item is called before or after clump finding. + self.clump_info = copy.deepcopy(clump_info) + # Function determining whether a clump is valid and should be kept. self.default_function = 'self.data.quantities["IsBound"](truncate=True,include_thermal_energy=True) > 1.0' if function is None: @@ -46,14 +54,53 @@ # Return value of validity function, saved so it does not have to be calculated again. self.function_value = None - def _isValid(self): - "Perform user specified function to determine if child clumps should be kept." - - # Only call function is it has not been already. - if self.function_value is None: - self.function_value = eval(self.function) + def add_info_item(self,quantity,format): + "Adds an entry to clump_info list and tells children to do the same." - return self.function_value + self.clump_info.append({'quantity':quantity, 'format':format}) + if self.children is None: return + for child in self.children: + child.add_info_item(quantity,format) + + def set_default_clump_info(self): + "Defines default entries in the clump_info array." + + # add_info_item is recursive so this function does not need to be. + self.clump_info = [] + + # Number of cells. + self.add_info_item('self.data["CellMassMsun"].size','"Cells: %d" % value') + # Gas mass in solar masses. + self.add_info_item('self.data["CellMassMsun"].sum()','"Mass: %e Msolar" % value') + # Volume-weighted Jeans mass. + self.add_info_item('self.data.quantities["WeightedAverageQuantity"]("JeansMassMsun","CellVolume")', + '"Jeans Mass (vol-weighted): %.6e Msolar" % value') + # Mass-weighted Jeans mass. + self.add_info_item('self.data.quantities["WeightedAverageQuantity"]("JeansMassMsun","CellMassMsun")', + '"Jeans Mass (mass-weighted): %.6e Msolar" % value') + # Max level. + self.add_info_item('self.data["GridLevel"].max()','"Max grid level: %d" % value') + # Minimum number density. + self.add_info_item('self.data["NumberDensity"].min()','"Min number density: %.6e cm^-3" % value') + # Maximum number density. + self.add_info_item('self.data["NumberDensity"].max()','"Max number density: %.6e cm^-3" % value') + + def clear_clump_info(self): + "Clears the clump_info array and passes the instruction to its children." + + self.clump_info = [] + if self.children is None: return + for child in self.children: + child.clear_clump_info() + + def write_info(self,level,f_ptr): + "Writes information for clump using the list of items in clump_info." + + for item in self.clump_info: + value = eval(item['quantity']) + output = eval(item['format']) + f_ptr.write("%s%s" % ('\t'*level,output)) + f_ptr.write("\n") def find_children(self, min, max = None): if self.children is not None: @@ -65,22 +112,41 @@ for cid in contour_info: new_clump = self.data.extract_region(contour_info[cid]) self.children.append(Clump(new_clump, self, self.field, - self.cached_fields,function=self.function)) + self.cached_fields,function=self.function, + clump_info=self.clump_info)) + + def pass_down(self,operation): + "Performs an operation on a clump with an exec and passes the instruction down to clump children." + + exec(operation) + + for child in self.children: + child.pass_down(operation) + + def _isValid(self): + "Perform user specified function to determine if child clumps should be kept." + + # Only call function if it has not been already. + if self.function_value is None: + self.function_value = eval(self.function) + + return self.function_value def __reduce__(self): return (_reconstruct_clump, (self.parent, self.field, self.min, self.max, - self.function_value, self.children, self.data, self.function)) + self.function_value, self.children, self.data, self.clump_info, self.function)) def __getitem__(self,request): return self.data[request] -def _reconstruct_clump(parent, field, mi, ma, function_value, children, data, + +def _reconstruct_clump(parent, field, mi, ma, function_value, children, data, clump_info, function=None): obj = object.__new__(Clump) if iterable(parent): parent = parent[1] if children is None: children = [] - obj.parent, obj.field, obj.min, obj.max, obj.function_value, \ - obj.children, obj.function = parent, field, mi, ma, function_value, children, function + obj.parent, obj.field, obj.min, obj.max, obj.function_value, obj.children, obj.clump_info, obj.function = \ + parent, field, mi, ma, function_value, children, clump_info, function # Now we override, because the parent/child relationship seems a bit # unreliable in the unpickling for child in children: child.parent = obj @@ -117,12 +183,11 @@ print "%d of %d children survived, erasing children." % (len(these_children),len(clump.children)) clump.children = [] - def write_clump_hierarchy(clump,level,f_ptr): for q in range(level): f_ptr.write("\t") f_ptr.write("Clump at level %d:\n" % level) - write_clump_info(clump,level,f_ptr) + clump.write_info(level,f_ptr) f_ptr.write("\n") f_ptr.flush() if ((clump.children is not None) and (len(clump.children) > 0)): @@ -132,7 +197,30 @@ def write_clumps(clump,level,f_ptr): if ((clump.children is None) or (len(clump.children) == 0)): f_ptr.write("%sClump:\n" % ("\t"*level)) - write_clump_info(clump,level,f_ptr) + clump.write_info(level,f_ptr) + f_ptr.write("\n") + f_ptr.flush() + if ((clump.children is not None) and (len(clump.children) > 0)): + for child in clump.children: + write_clumps(child,0,f_ptr) + +# Old clump info writing routines. +def write_old_clump_hierarchy(clump,level,f_ptr): + for q in range(level): + f_ptr.write("\t") + f_ptr.write("Clump at level %d:\n" % level) + clump.write_info(level,f_ptr) + write_old_clump_info(clump,level,f_ptr) + f_ptr.write("\n") + f_ptr.flush() + if ((clump.children is not None) and (len(clump.children) > 0)): + for child in clump.children: + write_clump_hierarchy(child,(level+1),f_ptr) + +def write_old_clumps(clump,level,f_ptr): + if ((clump.children is None) or (len(clump.children) == 0)): + f_ptr.write("%sClump:\n" % ("\t"*level)) + write_old_clump_info(clump,level,f_ptr) f_ptr.write("\n") f_ptr.flush() if ((clump.children is not None) and (len(clump.children) > 0)): @@ -151,7 +239,7 @@ """ -def write_clump_info(clump,level,f_ptr): +def write_old_clump_info(clump,level,f_ptr): fmt_dict = {'tl': "\t" * level} fmt_dict['num_cells'] = clump.data["CellMassMsun"].size, fmt_dict['total_mass'] = clump.data["CellMassMsun"].sum() _______________________________________________ Yt-svn mailing list Yt-svn(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-svn-spacepope.org

1 0

Re: [Yt-dev] new branch with lower overhead
by Matthew Turk 16 Jan '09

16 Jan '09

Looks like cic_deposit got turned on by mistake. svn up and it shoudl work. On Fri, Jan 16, 2009 at 11:49 AM, david collins <antpuncher(a)gmail.com> wrote: > I had a compile glitch. Building everything but hdf5 fresh, just to > check the whole script. Fails when it gets to yt. Didn't have such a > glitch with the trunk. > > Attached is the log file. > > d. > > On Fri, Jan 16, 2009 at 11:16 AM, Matthew Turk <matthewturk(a)gmail.com> wrote: >> thanks, sorry, was shooting from the hip. I guess I always thought of >> myself as William Munney, but evidently that was mistaken. >> >> On Fri, Jan 16, 2009 at 11:15 AM, Stephen Skory <stephenskory(a)yahoo.com> wrote: >>> >>>> http://svn.enzotools.org/yt/grid-optimization/ >>> >>> That link is broken, try: >>> >>> svn co http://svn.enzotools.org/yt/branches/grid-optimization/ yt-grid-op >>> >>> _______________________________________________ >>> Yt-dev mailing list >>> Yt-dev(a)lists.spacepope.org >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >>> >> _______________________________________________ >> Yt-dev mailing list >> Yt-dev(a)lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >

1 0

Re: [Yt-dev] mpi4py
by Stephen Skory 16 Jan '09

16 Jan '09

> Awesome, so it looks like it worked? Yup. All systems go on Ranger, at least with the Intel compilers I prefer to use. And I have been running out of the mpi4py trunk for a while now on Ranger, which hasn't changed for six months (see below). > And you said you were having problems on Kraken, yes? Was that with > 0.6.0 or with trunk? That was with trunk, the same version that I checked out on Ranger. sskory@kraken-pwd1:~/mpi4py-test> svn info Path: . URL: http://mpi4py.scipy.org/svn/mpi4py/mpi4py/trunk Repository Root: http://mpi4py.scipy.org/svn/mpi4py Repository UUID: 5e30ba94-2d20-0410-ad46-dcadf819b77c Revision: 180 Node Kind: directory Schedule: normal Last Changed Author: dalcinl Last Changed Rev: 179 Last Changed Date: 2008-06-02 14:25:05 -0400 (Mon, 02 Jun 2008) Here's the output: http://paste.enzotools.org/show/29/ It looks like I may just need to link to the correct mpi library/includes to get this to work. However, Matt, I'm still puzzled why you can get yours to work but not mine. There has to be a difference in our environments and modules on Kraken. sskory@kraken-pwd1:~/mpi4py-test> module list Currently Loaded Modulefiles: 1) modules/3.1.6 14) Base-opts/2.0.62 2) MySQL/4.0.27 15) PrgEnv-gnu/2.0.62 3) torque/2.3.0 16) xt-asyncpe/1.0 4) moab/5.2.2 17) xt-pe/2.0.62 5) xt-binutils-quadcore/2.0.0 18) xt-mpt/3.0.0 6) xtpe-quadcore 19) xt-libsci/10.2.1 7) xt-service/2.0.62 20) xt-totalview/8.4.1b 8) xt-libc/2.0.62 21) totalview-support/1.0.5 9) xt-os/2.0.62 22) gcc/4.2.0.quadcore 10) xt-catamount/2.0.62 23) subversion/1.4.6 11) xt-boot/2.0.62 24) imagemagick/6.4.2 12) xt-lustre-ss/2.0.62 25) java/jdk1.6.0_05 13) xtpe-target-cnl 26) globus/4.0.7 I'm pretty sure I'm using the same gcc (4.2.0) as I used to compile python, but I'm not at the point where that should make any difference, of course. _______________________________________________________ sskory(a)physics.ucsd.edu o__ Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_\(_)_______________

2 5

mpi4py
by Matthew Turk 16 Jan '09

16 Jan '09

Hi everyone, Unfortunately, due to problems with Kraken, we had to upgrade to using mpi4py from google code: http://code.google.com/p/mpi4py/ This means I had to change a bunch of calls in a backwards incompatible way, and the new buffering seems to be causing some issues occasionally. I haven't committed the changes yet because I was hoping to see how problematic installing the new version of MPI4py was for those of you using it (and not running off my install) -- which might just be Stephen, at this point. Additionally, I have to run some more test suites of problems, so I probably won't get it committed until this weekend. But if you could try building the mpi4py linked above: python setup.py build that would be helpful and demonstrative, and then we can see how to proceed. One of the problems (in my view, at least) with the new mpi4py is that it requires cython; fortunately, cython is surprisingly easy to install (but don't give it the access codes for the Caprican defenses) via either easy_install or just standard setup.py. -Matt

2 2

Re: [Yt-dev] yt: parameters in analysis
by Matthew Turk 14 Jan '09

14 Jan '09

Okay, what this speaks to is a failure of the field detection mechanism. What it is going on is that it is trying to identify your field dependencies. Because you directly address parameters instead of using the __getitem__ method, it's crapping out -- because the parameter file is mocked up with a defaultdict. So what I'd say needs to happen is twofold -- 1. Directly address data.pf["EquationOfState"] 2. The line "deps += ensure_list(fi[field].get_dependencies().requested)" should include a "pf = whatevs" so that it can directly address the parameter file. This will obviate the need for #1, but it might cause other problems, so it needs to be tested. However, all of that aside, what I think should be happening here is we need to get into a flow where you are not instantiating EnzoStaticOutput objects, but ratehr DaveStaticOutputs, which have their own field_info objects with your field subsets. Sometime I'll send you some code to do that; I think it will, ultimately, be the best thing for all of this. -Matt On Wed, Jan 14, 2009 at 3:10 PM, david collins <antpuncher(a)gmail.com> wrote: > Sure: > > http://paste.enzotools.org/show/24/ > > And when I do a post mortem, I get: >>>> pdb.pm() >> /nics/b/home/collins/yt/xtra_fields.py(191)_SoundSpeedSquared() > -> else: > (Pdb) data.pf > defaultdict(<function <lambda> at 0x8ccef50>, {}) > (Pdb) data.pf.keys() > [] > (Pdb) data.keys() > [] > > both of which are odd... > > d. > > On Wed, Jan 14, 2009 at 2:57 PM, Matthew Turk <matthewturk(a)gmail.com> wrote: >> Hey Dave, >> >> Can you send a bit more context in the traceback? This looks okay to >> me at first glance, because it's roughly the same thing as: >> >> http://yt.enzotools.org/browser/branches/yt-generalization/yt/lagos/EnzoFie… >> >> but it's tough to say without seeing a bit more, specifically how the >> field is getting called -- from which datatype. Feel free to submit >> to paste.enzotools.org as a traceback, if you like. >> >> -Matt >> >> On Wed, Jan 14, 2009 at 2:33 PM, david collins <antpuncher(a)gmail.com> wrote: >>> Hey, Matt-- >>> >>> My equation of state is driven by a flag in the parameter file, and >>> for isothermal runs, I don't have an energy field, and I store Sound >>> Speed as a parameter. So to get around this, when I need to get at >>> things like sound speed or gas pressure, I do the following: >>> >>> def _SoundSpeedSquared(field,data): >>> if data.pf.parameters['EquationOfState'] == 0: >>> return data.pf['Gamma']*data['GasPressure']/data['Density'] >>> else: >>> return data['Density']*0 + >>> (data.pf.parameters['IsothermalSoundSpeed'])**2 >>> >>> When I do a projection, it chokes in the following way: >>> >>> if data.pf.parameters['EquationOfState'] == 0: >>> AttributeError: 'collections.defaultdict' object has no attribute >>> 'parameters' >>> >>> What's the YT Approved way of getting to the parameter file info in analysis? >>> >>> d. >>> >> _______________________________________________ >> Yt-dev mailing list >> Yt-dev(a)lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >

1 0

Re: [Yt-dev] yt: parameters in analysis
by Matthew Turk 14 Jan '09

14 Jan '09

Hey Dave, Can you send a bit more context in the traceback? This looks okay to me at first glance, because it's roughly the same thing as: http://yt.enzotools.org/browser/branches/yt-generalization/yt/lagos/EnzoFie… but it's tough to say without seeing a bit more, specifically how the field is getting called -- from which datatype. Feel free to submit to paste.enzotools.org as a traceback, if you like. -Matt On Wed, Jan 14, 2009 at 2:33 PM, david collins <antpuncher(a)gmail.com> wrote: > Hey, Matt-- > > My equation of state is driven by a flag in the parameter file, and > for isothermal runs, I don't have an energy field, and I store Sound > Speed as a parameter. So to get around this, when I need to get at > things like sound speed or gas pressure, I do the following: > > def _SoundSpeedSquared(field,data): > if data.pf.parameters['EquationOfState'] == 0: > return data.pf['Gamma']*data['GasPressure']/data['Density'] > else: > return data['Density']*0 + > (data.pf.parameters['IsothermalSoundSpeed'])**2 > > When I do a projection, it chokes in the following way: > > if data.pf.parameters['EquationOfState'] == 0: > AttributeError: 'collections.defaultdict' object has no attribute > 'parameters' > > What's the YT Approved way of getting to the parameter file info in analysis? > > d. >

1 0

Abe
by Matthew Turk 13 Jan '09

13 Jan '09

Hi everybody, Have any of you run yt on Abe? Did you use the install script? Did it work out of the box? Which version of the install script was it? Thanks! -Matt

3 3

Re: [Yt-dev] color maps
by Matthew Turk 12 Jan '09

12 Jan '09

Hi Stephen, Try using 'c': http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.sca… -Matt On Sun, Jan 11, 2009 at 6:40 PM, Stephen Skory <stephenskory(a)yahoo.com> wrote: > Matt, > > I added a new callback in r1101 to print the halo particles, and I'm wondering how I can go about coloring each group separately? I made an array 'color' that works without error when used in the color= part of scatter, but changing the values of 'color' doesn't change the color of the points plotted. I think I need to pick a color map but it's not clear to me how to do that. I'm thinking that I'd also apply the same color map to the HopCircleCallback. Do you have any hints on how to do this? > > Take your time, of course! I am finishing work for the evening; I'm not waiting around on you. > > Thanks! > > _______________________________________________________ > sskory(a)physics.ucsd.edu o__ Stephen Skory > http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student > ________________________________(_)_\(_)_______________ > >

1 0