gmane.comp.python.fipy

Re: Problems on 3D Anisotropic Diffusion Coefficient

Zhiwen Liang — 2008-07-24T20:01:30

Hi, Thank you very much for your advice. I will try to update these things and see what happened. Like you said, it is probably not a big problem. Thanks again. I really appreciate it. Zhiwen On Thu, Jul 24, 2008 at 3:32 PM, Jonathan Guyer public.gmane.org> wrote:

Re: Problems on 3D Anisotropic Diffusion Coefficient

Jonathan Guyer — 2008-07-24T19:32:48

On Jul 24, 2008, at 2:07 PM, Zhiwen Liang wrote: OK. trunk/ has been updated since then, but I don't see anything likely to have had an affect on this. That's quite old (almost 2 years) and might be the source of this message.

Re: Problems on 3D Anisotropic Diffusion Coefficient

Zhiwen Liang — 2008-07-24T18:07:31

Hi, On Thu, Jul 24, 2008 at 1:21 PM, Jonathan Guyer public.gmane.org> wrote: Yes. Path: . URL: http://matforge.org/svn/fipy/trunk Repository Root: http://matforge.org/svn/fipy Repository UUID: d80e17d7-ff13-0410-a124-85740d801063 Revision: 2668 Node Kind: directory Schedule: normal Last Changed Author: wd15 Last Changed Rev: 2642 Last Changed Date: 2008-07-08 16:44:52 -0400 (Tue, 08 Jul 2008) numpy 1.0.1 pysparse 1.0.1 Thanks again, Zhiwen

Re: Problems on 3D Anisotropic Diffusion Coefficient

Jonathan Guyer — 2008-07-24T17:21:16

On Jul 24, 2008, at 11:14 AM, Zhiwen Liang wrote: "Warning" is not "Error". It is probably not a problem, although I don't know for sure. I don't see this warning when I run your script. You're using an svn checkout of trunk, right? Please report the revision number given by `svn info` What versions?

Re: Problems on 3D Anisotropic Diffusion Coefficient

Zhiwen Liang — 2008-07-24T15:14:21

Hi, On Thu, Jul 24, 2008 at 9:07 AM, Jonathan Guyer public.gmane.org> wrote: The error shows up immediately when the equation is solving. I just found it only appears several times at the first step. The rest of the steps work fine. So the 'error trace' is just a few lines of "Warning: invalid value encountered in divide". Maybe this is not a big problem? Mac OS X with version 10.4.11. Darwin Kernel Version 8.11.1 2.0a1. I installed both numpy and pysparse. Thank you very much for your suggestion. Zhiwen

Re: Mesh concatenation performance

Jonathan Guyer — 2008-07-24T13:50:18

On Jul 23, 2008, at 1:50 PM, Tony S Yu wrote: These all sound like reasonable changes (we never made any effort at efficiency in mesh concatenation, in the theory that it only happens once, before you start iterating; I won't argue that it can get tedious while you're troubleshooting, though). I'll look over your patch and apply it in the next day or two. Thanks very much for the contribution. ??? (almost) The first thing fipy.numerix does is `from numpy import *`, so all these functions are available and identical: >>> import numpy >>> from fipy import numerix >>> numpy.unique >>> numerix.unique >>> numpy.hstack >>> numerix.hstack >>> numpy.expand_dims >>> numerix.expand_dims >>> numpy.where >>> numerix.where >>> numpy.sort >>> numerix.sort >>> numpy.all >>> numerix.all The only purpose of fipy.numerix is to override behavior of NumPy that we don't like or need to augment (and to give us some insulation when they decide that Numeric, numarray, and numpy aren't enough and they need to release another, virtually identical library with a different name). In all other respects, fipy.numerix *is* numpy.

Re: Problems on 3D Anisotropic Diffusion Coefficient

Jonathan Guyer — 2008-07-24T13:07:44

On Jul 24, 2008, at 12:11 AM, Zhiwen Liang wrote: At what point? Immediately or after awhile? Your script runs fine for me, so I can't diagnose. Please post the error trace. What platform are you running on? Precisely what version of FiPy? What supporting libraries (NumPy, PySparse, etc.)? P.S. I'd like to recommend once again not to start with such a big mesh when you don't even know if things work yet. You can diagnose a 5**3 mesh a thousand times faster than a 50**3 mesh. P.P.S. There is no need to "sweep" this problem as there are no non- linearities

Problems on 3D Anisotropic Diffusion Coefficient

Zhiwen Liang — 2008-07-24T04:11:51

Mesh concatenation performance

Tony S Yu — 2008-07-23T17:50:42

Thanks Jon and Daniel for your help with my previous question on fixing the concentration of a cell. I was playing around with concatenating meshes, and I noticed that the concatenation code was quite slow for me. All the magic seemed to happen in mesh._getAddedMeshValues, so I messed around with the code a bit: I flattened a couple of nested loops (at the cost of memory; I don't know if this is an issue) and the performance improved a bit. I also changed the code to iterate only over exterior vertices to check for vertex matching (I imagine that's the only place you want to check for mesh correlation, but I could be wrong). There's probably a few more things that can be done, but I decided I don't need to concatenate meshes (for now, at least) so I shouldn't put anymore time into it. If you're interested, I've included a patch. All tests pass (except some small numpy 1.1 issues which existed previously) on my computer, but it should probably be tested on numpy 1.0.4. There's a little more noise in the patch than there should be because I ended up moving two blocks of code in mesh._getAddedMeshValues to separate methods (mesh._getVertexCorrelates and mesh._getFaceCorrelates). These blocks were already labeled by comments in the code, and it was easier for me to read the code this way. I can move them back if you prefer. Unfortunately, some numpy methods I wanted to use weren't available in tools.numerix so I added an import numpy statement to the top of `mesh.py`. I can add a thin numerix wrapper to these functions if that's the prefered style. (NOTE: It's possible these methods don't work the same in an older numpy). Cheers, -Tony

Re: Problems on Installing New Fipy

Zhiwen Liang — 2008-07-21T21:16:46

On Mon, Jul 21, 2008 at 1:20 PM, Daniel Wheeler public.gmane.org> wrote: The contents of the file is: from numpy import Int8, UInt8, \ Int16, UInt16, \ Int32, UInt32, \ Float32, Float64, \ Complex32, Complex64, \ Float, Int, Complex class _TypeNamespace: """Numeric compatible type aliases for use with extension functions.""" Int8 = Int8 UInt8 = UInt8 Int16 = Int16 UInt16 = UInt16 Int32 = Int32 UInt32 = UInt32 Float32 = Float32 Float64 = Float64 Complex32 = Complex32 Complex64 = Complex64 nx = _TypeNamespace() from numpy import inf, infty, Infinity infinity = Infinity The version is 0.87.3. I replaced the import part in the file _sp_import.py to be: try: from numpy.oldnumeric import Int8, UInt8, \ Int16, UInt16, \ Int32, UInt32, \ Float32, Float64, \ Complex32, Complex64, \ Float, Int, Complex except ImportError: from numpy import Int8, UInt8, \ Int16, UInt16, \ Int32, UInt32, \ Float32, Float64, \ Complex32, Complex64, \ Float, Int, Complex Then I can get through this file. But there are a lot of other files that need to be modified, i.e., replacing the numpy by numpy.oldnumeric. I guess this matplotlib is just too old but I could not find a right version for it. I think I will try to do it in another machine that use python2.4 or python2.5. Or use other viewers to view the results. Thank you very much for your times. I really appreciate it. Zhiwen

Re: Problems on Installing New Fipy

Daniel Wheeler — 2008-07-21T17:20:11

On Mon, Jul 21, 2008 at 11:02 AM, Zhiwen Liang public.gmane.org> wrote: Paste the contents of "/sw/lib/python2.3/site-packages/matplotlib/numerix/_sp_imports.py" in an email. What version of matplotlib do you have? Look in "/sw/lib/python2.3/site-packages/matplotlib/__init__.py" and look for "__version__" to find out.

Re: Problems on Installing New Fipy

Zhiwen Liang — 2008-07-21T15:02:41

Hi On Mon, Jul 21, 2008 at 10:17 AM, Jonathan Guyer public.gmane.org> wrote: Regarding Daniel's question, I have the following output. What happens when you do "python -c 'from numpy.oldnumeric import Int8'"? I can import Int8 this way. What happens when you do "python -c 'from numpy import Int8'"? The error is: Traceback (most recent call last): File "", line 1, in ? ImportError: cannot import name Int8 What happens when you do "python -c 'import numpy; print numpy.__version__'"? It is 1.0.1 Fink still provide matplotlib for python 2.3, but from the errors I got, I have a feeling that this version is not compatible with the numpy I have. So I tried to download the source code and install myself but could not find anything for python 2.3. Sorry if I confused you. Thanks again, Zhiwen

Re: Problems on Installing New Fipy

Jonathan Guyer — 2008-07-21T14:17:56

On Jul 19, 2008, at 11:44 AM, Zhiwen Liang wrote: Interesting. I need to figure out why viewers.make() doesn't report this error message to you, instead of the one about pylab.io() (mind you, I'd have had no idea where this error message was coming from, so we'll need to figure out an easier way to report backtraces for failing viewers). In the meantime, please do provide the diagnostics that Daniel asked for. Understood. I just wanted to be certain that you were getting the import you thought you were; I've had subtle things happen with .pth files and such. While I'm glad you agree, I'm a little puzzled. I thought the whole point of fink was that it kept different packages consistent with one another. If you have python 2.3, then it should be loading an appropriate version of matplotlib or it should be insisting that you install a newer version of python.

Re: Front-fixing method for moving boundary problem

Jonathan Guyer — 2008-07-21T14:17:53

On Jul 20, 2008, at 7:35 AM, Etienne Rivard wrote: chacun à son goût Understood. When you get it done, if you wanted to contribute said elegant solution to FiPy, we'd be delighted.

Re: Problems on Installing New Fipy

Daniel Wheeler — 2008-07-21T14:04:02

What happens when you do "python -c 'from numpy.oldnumeric import Int8'"? What happens when you do "python -c 'from numpy import Int8'"? What happens when you do "python -c 'import numpy; print numpy.__version__'"? On Sat, Jul 19, 2008 at 11:44 AM, Zhiwen Liang public.gmane.org> wrote:

Re: Front-fixing method for moving boundary problem

Etienne Rivard — 2008-07-20T11:35:40

Jonathan Guyer wrote: I'll trust you on that ;-) Right. I remember once considering swithcing to another method like the phase field method to solve my problem. But I have to admit I was somewhat demotivated by the apparent complexity of the method. For the moment, I don't think I'll get deeper into that. Thanks for the offer, I appreciate it but. I have time to work on this and this actually a part of my PhD work so I need to show a deep understanding of everything I use, so I would rather shoot for a more elegant solution. Also, it makes me feel really good to know that this problem is not as simple as it looks and actually requires some thought. I'll have a close look at that. Thanks for the valuable input. Etienne

Re: Problems on Installing New Fipy

Zhiwen Liang — 2008-07-19T15:44:20

Hi Jon, When I "import pylab", I got: Traceback (most recent call last): File "", line 1, in ? File "/sw/lib/python2.3/site-packages/pylab.py", line 1, in ? from matplotlib.pylab import * File "/sw/lib/python2.3/site-packages/matplotlib/pylab.py", line 196, in ? import cm File "/sw/lib/python2.3/site-packages/matplotlib/cm.py", line 5, in ? import colors File "/sw/lib/python2.3/site-packages/matplotlib/colors.py", line 33, in ? from numerix import array, arange, take, put, Float, Int, where, \ File "/sw/lib/python2.3/site-packages/matplotlib/numerix/__init__.py", line 68, in ? from _sp_imports import nx, infinity File "/sw/lib/python2.3/site-packages/matplotlib/numerix/_sp_imports.py", line 1, in ? from numpy import Int8, UInt8, \ ImportError: cannot import name Int8 So I could not do "pylab.__file__". I confirmed there is only this pylab.py in my computer because if I uninstall matplotlib, there will be no module called pylab. I agreed that python 2.3 is too old. Matplotlib now only releases new versions for python 2.4 and higher. Thanks, Zhiwen On Fri, Jul 18, 2008 at 10:52 PM, Jonathan Guyer public.gmane.org> wrote:

Re: Problems on Installing New Fipy

Jonathan Guyer — 2008-07-19T02:52:50

On Jul 18, 2008, at 4:00 PM, Zhiwen Liang wrote: Yes, I know. I wrote it. Can I suggest that both of our time would be better spent if you sent me the specific output that I asked for rather than trying figure out and then explain to me how my own code works? Nor am I. Python 2.4 and 2.5 don't do this. I suspect that it was a bug, or at least a bad design, in Python 2.3. As Daniel has said, Python 2.3 is quite old (3 1/2 years, now) and you would likely benefit in many ways from not using something so obsolete. Variable.__nonzero__() was only introduced about a month ago. Again. Please, Please, *PLEASE* send me the output that I asked for. What does >>> import pylab >>> pylab.__file__ output? Seriously. I want to know.

Re: Problems on Installing New Fipy

Zhiwen Liang — 2008-07-18T20:00:07

Hi, Thank you for all the concerns. Let's get one thing at a time. I found the reason for error of "The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()". In the 'make' function of viewers/__init__.py, after it creates a viewer for one of the variable of the list of variables passed into the function, it will delete that variable and create viewer for the next one, until the list of variables is empty. So that's what Line 102-103 in viewers/__init__.py do. It is the "remove" in Line 103 that causes the problem. For example, if I run: from fipy import * mesh=Grid1D(nx=5) var=CellVariable(mesh=mesh,value=[1,2,3,4,5]) varlist=[var] varlist.remove(var) Then I get the error of: Traceback (most recent call last): File "", line 1, in ? File "/Users/liangz/Library/Python/2.3/site-packages/FiPy-2.0a1-py2.3.egg/fipy/variables/variable.py", line 1112, in __nonzero__ return bool(self.getValue()) ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() which is the same as the error for making a gistViewer. The trace back shows that "remove" somehow uses the function of "__nonzero__" in variables/variables.py. And "var.getValue()" in that function returns a list. Taking the boolean of a list causes the error. But I am not sure why "remove" will use "__nonzero__". I tried "vars.remove(var)" in an older version of fipy and it works fine. I am still checking my other installation problems to see if I made some stupid mistakes. Thanks again. Zhiwen On Fri, Jul 18, 2008 at 10:39 AM, Jonathan Guyer public.gmane.org> wrote:

Re: Front-fixing method for moving boundary problem

Jonathan Guyer — 2008-07-18T16:30:07

On Jul 18, 2008, at 6:59 AM, Etienne Rivard wrote: I'm glad it was helpful. Now we just need to figure out how to properly document it and make it a bit more transparent for users to actually do. We wrote FiPy for solving phase field and level set problems, because we didn't ever want to think about "the moving boundary difficulty"! 8^) I believe you'll want to divide through by $s^2$ and render this as \[ \nabla\cdot\left(\frac{1}{s^2} u \right) = \frac{\partial u}{\partial t} - \nabla\cdot\left(\xi \frac{1}{s} \frac{d s}{d t} u \right) + \frac{1}{s} \frac{d s}{d t} u \] or DiffusionTerm(coeff=1/s**2) == TransientTerm() - PowerLawConvectionTerm(coeff=xi * sdot / s) + ImplicitSourceTerm(coeff=sdot / s) You want to use this as an ODE to solve for s or as a boundary condition on u? Either way, you need at least one more BC on u. You'll need to explicitly track $s_{old}$, as only CellVariables have that property. Alternatively, you could set up a one-element mesh and make $s$ a CellVariable on that mesh and solve it as a PDE, but we're pretty sure you'll have trouble communicating values back and forth between the two different meshes. I think FiPy will raise an error if you try to use $s$, defined on one mesh, as a coefficient for solving a variable on a different mesh, but maybe you'll get lucky... no, unfortunately you won't. I just tried: >>> from fipy import * >>> mesh = Grid1D(nx=10) >>> xi = mesh.getCellCenters() >>> u = CellVariable(mesh=mesh, hasOld=True) >>> smesh = Grid1D(nx=1) >>> s = CellVariable(mesh=smesh, value=1. hasOld=True) >>> dt = 1. >>> sdot = (s - s.getOld()) / dt >>> eq = DiffusionTerm(coeff=1/s**2) == TransientTerm() - PowerLawConvectionTerm(coeff=xi * sdot / s) + ImplicitSourceTerm(coeff=sdot / s) I was shocked to actually get this far, but when I tried: >>> s.updateOld() >>> s.setValue(2.) >>> eq.solve(vars=u) it throws "ValueError: shape mismatch: objects cannot be broadcast to a single shape" It turns out this is because both DiffusionTerm and ConvectionTerm want their coefficients as FaceVariables, and will interpolate a CellVariable to a FaceVariable if necessary, but a FaceVariable on smesh has two faces, instead of the optimal 1 or acceptable 11. I can probably come up with an ugly hack to avoid this, but will need to think about it. To get $\left. \frac{\partial u}{\partial \xi}\right|_{\xi = 1}$, I think you may need to resort to the techniques discussed in this recent thread: http://thread.gmane.org/gmane.comp.python.fipy/973 but maybe Daniel or Recif has something better?

Re: Problems on Installing New Fipy

Jonathan Guyer — 2008-07-18T14:39:56

On Jul 17, 2008, at 5:30 PM, Zhiwen Liang wrote: Python imports can be kind of tricky sometimes, which is why I asked you to report the result of >>> import pylab >>> pylab.__file__ Meaning what? I don't believe it's possible to get the error "'module' object has no attribute 'ion'" without importing *something*. If `import pylab` fails, then you should have gotten a different error message from `viewers.make()`. No, it doesn't only use gistViewer. It uses the first viewer that it can find that actually works. gistViewer and gnuplotViewer failed, so it tried matplotlibViewer. I addressed that one first, because the error was easier to diagnose. I don't know why your other viewers are throwing "The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()". examples/diffusion/mesh1D.py does not generate that error with any of our viewers. Have you modified the example in any way? Are you running the tip of trunk/? To determine what is the problem, please edit fipy/viewers/__init__.py and at line 108, please add except Exception: raise *above* the line that says `except Exception, s` and then report back the full text of the error trace. Yes. It's one result of our switch to setuptools. gcc is not the problem. The Python interpreter has changed since some library was compiled against it. That's not FiPy because FiPy is not compiled. Likely candidates are PySparse, NumPy, SciPy, or any of the viewers.