Matt,
> Maybe I missed the multiplication by two for the two possible
> incrementations, so maybe it should be:
>
> s = (ny*nx + nx*nz + nx*nz - 2) * 18
The issue is a typo, which is not surprising with those crazy numbers I got. Above is wrong, below is correct and is working in my tests.
s = (ny*nx + nx*nz + ny*nz - 2) * 18
Stephen Skory
stephenskory(a)yahoo.com
http://stephenskory.com/
510.621.3687 (google voice)
Hi Matt,
> And it might be easier if you figured out why it was broken ratehr
> than waiting on me. The issue is in the .pyx, not the .py file, and
> it is that the buffer of potential contour linkages is not long
> enough. I thought it was, based on the loop structure that followed.
> If you expand it to the correct length it will work.
I've done some work on this, and you're right that the buffer in construct_boundary_relationships needs to be made bigger. In some cases, much bigger. The multiplier was set to 9:
s = (ny*nx + nx*nz + nx*nz - 4) * 9
In my dataset I've found that I need at least 52 for it to work in all cases. I did some statistics and the mean minimum multiplier required is 18 with a standard deviation of 9, so 52 is about 3 sigma out, so it's not that rare. I don't know how globally-applicable these statistics are; this is just one dataset.
What I'm wondering is what we should do about this? Make the multiplier large enough to capture (N)sigma likelihood? Or wrap the call to construct_boundary_relationships in countour_finder.py in a while loop with a try/except that increases the multiplier with each failure?
Stephen Skory
stephenskory(a)yahoo.com
http://stephenskory.com/
510.621.3687 (google voice)
Hi all,
I'd like to move the install script to 2.7. This seems to fix all the
issues with the install script on OSX, but it means everyone's muscle
memory will have to be corrected if you're used to typing "python2.6".
(An alternative would be to add an alias, "pyyt" or something.)
[+-][01] on Python 2.7?
One additional question, what would people think about a "bootstrap"
script being included that users are encouraged to run following the
installation script? This script could set up ~/.hgrc and also create
a bitbucket user from the CLI. What do you think?
[+-][01] on optional bootstrap script?
If we have support for item 1, I'll push it out sometime later this
week. #2 would be on the few week timescale. (Lots of non-yt
projects I'm focusing on for a while.)
-Matt
All,
> [+-][01] on Python 2.7?
+1. 2.7 will be the last 2.x series, so until we go to 3.x, there will be no more changes required.
> [+-][01] on optional bootstrap script?
-1. I think a better use of our time would be to write some docs on how to get started using bitbucket in the context of yt, with links to BB's docs as well as the various hg docs. Make this prominent on the homepage, and in the install script at the end of the process.
All,
> For periodicity, please do not put the check inside the loop. Check
> outside the loop if it looks like it wraps around the domain, and
> recenter it so that it does not.
That's reasonable. I'll try to do it that way.
> For the second issue, I almost have a working import script to go from
> Trac to BitBucket. Please don't report it there.
That's what I was thinking about. Righto.
> And it might be easier if you figured out why it was broken ratehr
> than waiting on me. The issue is in the .pyx, not the .py file, and
> it is that the buffer of potential contour linkages is not long
> enough. I thought it was, based on the loop structure that followed.
> If you expand it to the correct length it will work.
I'll see what I can do.
Stephen Skory
stephenskory(a)yahoo.com
http://stephenskory.com/
510.621.3687 (google voice)
Hi All,
a couple questions:
1. With help from Matt I'm currently working on a treecode gravitational potential calculation using the Octree. Looking at FindBindingEnergy in data_point_utilities, periodicity is not considered there. I think that that should be fixed, and I'll include it in this new code. Do we agree?
2. A few weeks ago I raised the issue that
yt/utilities/_amr_utils/ContourFinding.pyx
yt/analysis_modules/level_sets/contour_finder.py
are broken after changeset fd91f581b0e0. Should I put this into the bug tracker on Trac?
Thanks!
Stephen Skory
stephenskory(a)yahoo.com
http://stephenskory.com/
510.621.3687 (google voice)
Matt & Britton,
>OS 10.6 comes with python 2.6. Would it be better if they just used that python and didn't try to build another one? Can we add another flag to the install script to optionally build python?
Along the same lines, we could write some instructions on using yt with enthought python. It comes with many handy things...
>>>>Can you check the options in ./configure, and if none of those are
There is no preference for that in ./configure AFAICT.
>>>>obvious, can you investigate how much work getting a localize gettext
>>>>to install is?
I installed gettext - it didn't help.
> Or, better yet, maybe this is improved/fixed in python
>>>>2.7, and you could test that?
I might try that out.
Stephen Skory
stephenskory(a)yahoo.com
http://stephenskory.com/
510.621.3687 (google voice)
Matt,
briefly - I tried the new script on my mac, without any of the libintl naming funny-business I mentioned before, and the install progressed to the end. Interestingly, I got the same missing symbol problem as before, but it passed over it without any other problems. So... I guess it's a fix?
Stephen Skory
stephenskory(a)yahoo.com
http://stephenskory.com/
510.621.3687 (google voice)
Hi Matt,
I think I've found a solution, of sorts. Let me know what you think, and I'll (or you can) pass it back to yt-users. Try as I might, installing what provides libintl, which is gettext, or temporarily renaming various libintl libs on my system didn't work. I noticed that my virgin system had no libintl on it at all. It turns out that disabling the inclusion of libintl during the Python build process appears to do the trick. I simply renamed my libintl.h file, but a more elegant solution would be to turn it off during the Python build process. Well, a more elegant solution would be to figure out why libintl on the mac doesn't appear to have all the right symbols. But that's not instant gratification.
Stephen Skory
stephenskory(a)yahoo.com
http://stephenskory.com/
510.621.3687 (google voice)
Hi Matt,
I haven't solved anything, but I can confirm that your suspicion of conflicting libraries is likely correct. On my lappy (10.6.6) which has lots of historical upgrades and cruft, I too am seeing the same error. I have access to a virgin 10.6.6 machine, and things appear to have gone smoothly.
If I learn anything new, I'll let you know.
Stephen Skory
stephenskory(a)yahoo.com
http://stephenskory.com/
510.621.3687 (google voice)
