Re: strange result with gnuplot viewer
The gnuplot viewer classes were written a long time ago and we don't use them.
Any patches by knowledgeable gnuplot users would be welcome.
On Jul 15, 2010, at 3:51 PM, Benny Malengier wrote:
Hi,
I obtain a strange resulting figure with Gnuplot2DViewer, which is due to the
line:
self.g('set dgrid3d %i, %i, 2' % (ny, nx))
It is more correct with
self.g('set dgrid3d %i, %i, 16' % (ny, nx))
I find the gnuplot explanation lacking however:
http://www.nada.kth.se/cgi-bin/info?%28gnuplot.info%29set%20dgrid3d
I would be interested if somebody could run his examples also for
gnuplot2dviewer with norm 16 to see if there is a problem with changing this
from 2 to 16 for all cases (as opposed to my hack for my specific problem).
Or perhaps somebody is more knowledgable with gnuplot?
Benny
Re: ndarray has dot function in numpy trunk
On Jul 16, 2010, at 5:41 AM, Benny Malengier wrote: test file for this bug in attachment. old = True fails with numpy trunk, old=False works Thanks for your reports on the new NumPy, Benny. There are clearly some issues we need to deal with. Could you please file this report and your test as a ticket in Trac? So the fix would be to not allow casting to array automatically for a variable. Not idea if that is a problem for fipy. That's not a trivial change, but we've debated it at times for other reasons. This may be time to revisit it.
Re: ndarray has dot function in numpy trunk
Hi Benny, The issue below is caused because mesh getter methods do not, in general, return Variable objects, but simply numpy arrays. The only method that does currently return a Variable is getCellCenters(). We should probably be clearer about this. Hope this helps. On Fri, Jul 16, 2010 at 4:41 AM, Benny Malengier benny.maleng...@gmail.com wrote: I hit a much more problematic thing with this numpy. The code from fipy.meshes.numMesh.grid2D import Grid2D mesh = Grid2D(dx=0.1, dy=0.1, nx=10, ny=10) ap = CellVariable(mesh=mesh, value=0.01) coeff = mesh._getFaceAreas() * mesh._getCellDistances() / \ ap.getArithmeticFaceValue() print 'coval', type(coeff), type(coeff.getValue()) Now fails with: AttributeError: 'MaskedArray' object has no attribute 'getValue' So coeff is a MaskedArray, while on older numpy it is the expected binOp I'm investigating what is causing it. Benny 2010/7/15 Jonathan Guyer gu...@nist.gov On Jul 15, 2010, at 3:02 AM, Benny Malengier wrote: It seems ndarray has a dot function now in numpy trunk, updated my numpy and fipy crashes like ... Thanks for the alert -- Daniel Wheeler
Re: ndarray has dot function in numpy trunk
On Jul 16, 2010, at 10:15 AM, Daniel Wheeler wrote: Hi Benny, The issue below is caused because mesh getter methods do not, in general, return Variable objects, but simply numpy arrays. The only method that does currently return a Variable is getCellCenters(). We should probably be clearer about this. Hope this helps. It's more subtle than that, because Benny says this worked with older numpy's. The logic that dictates whether we get a look at an operation before numpy or ma takes over is tricky and it looks like it's changed.
Re: ndarray has dot function in numpy trunk
2010/7/16 Jonathan Guyer gu...@nist.gov On Jul 16, 2010, at 10:15 AM, Daniel Wheeler wrote: Hi Benny, The issue below is caused because mesh getter methods do not, in general, return Variable objects, but simply numpy arrays. The only method that does currently return a Variable is getCellCenters(). We should probably be clearer about this. Hope this helps. It's more subtle than that, because Benny says this worked with older numpy's. The logic that dictates whether we get a look at an operation before numpy or ma takes over is tricky and it looks like it's changed. Yes, it is examples/flow/stokesCavity.py that fails with numpy trunk. I'll submit the ticket later today. Benny
Re: ndarray has dot function in numpy trunk
2010/7/16 Jonathan Guyer gu...@nist.gov On Jul 16, 2010, at 5:41 AM, Benny Malengier wrote: test file for this bug in attachment. old = True fails with numpy trunk, old=False works Thanks for your reports on the new NumPy, Benny. There are clearly some issues we need to deal with. Could you please file this report and your test as a ticket in Trac? Done: http://matforge.org/fipy/ticket/303 http://matforge.org/fipy/ticket/304 Should be sufficiently verbose that people will hit it with google should they run into it before fipy is changed Benny
