stupid error in trunk

[Benny Malengier]

Hi,

There is a stupid indent error in trunk at the moment:

  File testbenny_viscous2.py, line 90, in module
from fipy import *
  File
/usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/__init__.py, line
41, in module
from solvers import *
  File
/usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/solvers/__init__.py,
line 26, in module
from fipy.solvers.pysparse import *
  File
/usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/solvers/pysparse/__init__.py,
line 7, in module
from linearPCGSolver import LinearPCGSolver
  File
/usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/solvers/pysparse/linearPCGSolver.py,
line 42, in module
from fipy.solvers.pysparse.preconditioners import SsorPreconditioner
  File
/usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/solvers/pysparse/preconditioners/__init__.py,
line 2, in module
from ssorPreconditioner import SsorPreconditioner
  File
/usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/solvers/pysparse/preconditioners/ssorPreconditioner.py,
line 36
from fipy.solvers.pysparse.preconditioners.preconditioner import
Preconditioner


Does this mean the developers themself don't use pysparse a lot?
Note that I need to pass the --pysparse flag to the script, or I get an
import error:

$ python testbenny_viscous2.py
Traceback (most recent call last):
  File testbenny_viscous2.py, line 90, in module
from fipy import *
  File
/usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/__init__.py, line
41, in module
from solvers import *
  File
/usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/solvers/__init__.py,
line 40, in module
raise ImportError, Could not import any solver package. If you are
using Trilinos, make sure you have all of the necessary Trilinos packages
installed - Epetra, EpetraExt, AztecOO, Amesos, ML, and IFPACK.
ImportError: Could not import any solver package. If you are using Trilinos,
make sure you have all of the necessary Trilinos packages installed -
Epetra, EpetraExt, AztecOO, Amesos, ML, and IFPACK.

Greetings,
Benny Malengier

Re: stupid error in trunk

[Benny Malengier]

2010/6/24 Daniel Wheeler daniel.wheel...@gmail.com


 Appears to have been fixed 3 days ago:


 http://matforge.org/fipy/changeset/3642/trunk/fipy/solvers/pysparse/preconditioners/ssorPreconditioner.py
 


Sorry for the noise. I did svn up before posting, but probably in the wrong
directory (was working in example).

Greetings,
Benny


 On Thu, Jun 24, 2010 at 9:35 AM, Benny Malengier
 benny.maleng...@gmail.com wrote:
  Hi,
 
  There is a stupid indent error in trunk at the moment:
 
File testbenny_viscous2.py, line 90, in module
  from fipy import *
File
  /usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/__init__.py,
 line
  41, in module
  from solvers import *
File
 
 /usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/solvers/__init__.py,
  line 26, in module
  from fipy.solvers.pysparse import *
File
 
 /usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/solvers/pysparse/__init__.py,
  line 7, in module
  from linearPCGSolver import LinearPCGSolver
File
 
 /usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/solvers/pysparse/linearPCGSolver.py,
  line 42, in module
  from fipy.solvers.pysparse.preconditioners import SsorPreconditioner
File
 
 /usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/solvers/pysparse/preconditioners/__init__.py,
  line 2, in module
  from ssorPreconditioner import SsorPreconditioner
File
 
 /usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/solvers/pysparse/preconditioners/ssorPreconditioner.py,
  line 36
  from fipy.solvers.pysparse.preconditioners.preconditioner import
  Preconditioner
 
 
  Does this mean the developers themself don't use pysparse a lot?
  Note that I need to pass the --pysparse flag to the script, or I get an
  import error:
 
  $ python testbenny_viscous2.py
  Traceback (most recent call last):
File testbenny_viscous2.py, line 90, in module
  from fipy import *
File
  /usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/__init__.py,
 line
  41, in module
  from solvers import *
File
 
 /usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/solvers/__init__.py,
  line 40, in module
  raise ImportError, Could not import any solver package. If you are
  using Trilinos, make sure you have all of the necessary Trilinos packages
  installed - Epetra, EpetraExt, AztecOO, Amesos, ML, and IFPACK.
  ImportError: Could not import any solver package. If you are using
 Trilinos,
  make sure you have all of the necessary Trilinos packages installed -
  Epetra, EpetraExt, AztecOO, Amesos, ML, and IFPACK.
 
  Greetings,
  Benny Malengier
 



 --
 Daniel Wheeler

Re: dump.write not writing out correct mesh

[Benny Malengier]

This is actually already in the bug tracker I notice:
http://matforge.org/fipy/ticket/243

I've hit some other bugs this weekend I'll submit on the tracker.

Benny

2010/6/26 Benny Malengier benny.maleng...@gmail.com

 Hello,

 From the FAQ and examples it is said to write out variables with
 dump.write, and reuse them with dump.read (eg
 http://osdir.com/ml/python.fipy/2008-04/msg2.html).

 I have made a non-rectangular U-shaped grid by concatenating different
 grid2D, but after dump.write/dump.read, the mesh is not correct. Anybody an
 idea where I could start debugging this? Or are there other ways to do this,
 eg dumping specific parts of the mesh objects.

 Greetings,
 Benny

Re: dump.write not writing out correct mesh

[Benny Malengier]

I do not find a registration button on https://matforge.org/fipy
Should all bugs be anonymous? I rather have a login on bug trackers. It does
not say on https://matforge.org/fipy/newticket if your email address will be
hidden on the tracker if you give that. Does it?

Note that this mailing list replies with a fake To address of:
Multiple recipients of list fipy@nist.gov
This is highly annoying in eg gmail and other clients. Can this setting not
be changed, this is the first mailing list I am on that behaves like this.

Benny

2010/6/28 Benny Malengier benny.maleng...@gmail.com

 This is actually already in the bug tracker I notice:
 http://matforge.org/fipy/ticket/243

 I've hit some other bugs this weekend I'll submit on the tracker.

 Benny

 2010/6/26 Benny Malengier benny.maleng...@gmail.com

 Hello,


 From the FAQ and examples it is said to write out variables with
 dump.write, and reuse them with dump.read (eg
 http://osdir.com/ml/python.fipy/2008-04/msg2.html).

 I have made a non-rectangular U-shaped grid by concatenating different
 grid2D, but after dump.write/dump.read, the mesh is not correct. Anybody an
 idea where I could start debugging this? Or are there other ways to do this,
 eg dumping specific parts of the mesh objects.

 Greetings,
 Benny

Re: dump.write not writing out correct mesh

[Benny Malengier]

2010/6/28 Jonathan Guyer gu...@nist.gov


  Note that this mailing list replies with a fake To address of:
  Multiple recipients of list fipy@nist.gov

 As opposed to what?


As opposed to leaving the To address I give alone.
The reply to address of this list is clearly listed as  fipy@nist.gov,
however, mails arrive with address: Multiple recipients of list 
fipy@nist.gov
So the mailing client is doing a substitution that fools for example gmail
in collapsing the send and arriving mail.

Note that a nice feature of mailing lists is adding the mailing list to the
subject line, sourceforge does that for example, allowing to quicker wade
through mails.
I know, little things, but they add up increasing usability.


  This is highly annoying in eg gmail and other clients. Can this setting
 not be changed, this is the first mailing list I am on that behaves like
 this.

 Changed to what?


Changed to doing no substitution of the To address to the one it is doing
now.

Benny

design decision of UniformGrid

[Benny Malengier]

Hi,

First, I'd like to mention I'm happy with how fipy is handling the problem
I'm throwing at it.
I just write here to offer some insight from a user using fipy for the first
time.

I would just like to mention that I do not like the design chosen for the
UniformGrid2D structure.

I have struggled with a bug for a long time because it was unclear that a
Grid2D created from
from fipy import *
can be a Grid2D or a UniformGrid2D

I think it would be a better design if Grid2D in meshes.numMesh is renamed
NonUniformGrid2D.

I also find it impossible to write generic code that can work on all meshes.
UniformGrid2D does not call the __init__ method of it's parent class. I find
that a dangerous way of writing inheritance. Eg, for UniformGrid2D,
self.areaProjections attribute is not present, altough it is an attribute of
the parent object (it is set in __init__ of /meshes/common/mesh.py).

The fix for me is easy of course:

from fipy import *
from fipy.meshes.numMesh.grid2D import Grid2D

but it would be nice if this is not needed, eg by adding the __init__ or by
making in the manual mush clearer that Grid2D is not the nummesh/Grid2D.

Greetings,
Benny

flow field example, pressure oscillation

[Benny Malengier]

Hi,

I am doing a flow field calculation like
http://www.ctcms.nist.gov/fipy/examples/flow/generated/examples.flow.stokesCavity.html

However, I obtain spurious oscillations for the pressure solution. Patankar
in his works is very clear that a staggered grid should be used for the
SIMPLE algorithm, in the example averaging is applied so as to work on one
grid, which I believe leads to these oscillations.

Does anybody has an idea how best to alleviate this problem? I am thinking
about eg a CornerCellVariable for vx/vy, which would be the staggered grid.
In essense that means a mesh holds two grids then. It becomes complicated
fast however.
Perhaps other ideas? Or better to calculate the flow field with another
tool?

Greetings,
Benny

ndarray has dot function in numpy trunk

[Benny Malengier]

Hi,

It seems ndarray has a dot function now in numpy trunk, updated my numpy and
fipy crashes like

  File stratifiedmassflowrect.py, line 44, in module
mesh1 = Grid2D(dx=dy1strat, nx=nytot, dy=dz, ny=nztot)
  File
/usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/meshes/numMesh/grid2D.py,
line 111, in __init__
Mesh2D.__init__(self, vertices, faces, cells)
  File
/usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/meshes/numMesh/mesh.py,
line 68, in __init__
_CommonMesh.__init__(self)
  File
/usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/meshes/common/mesh.py,
line 68, in __init__
self._calcGeometry()
  File
/usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/meshes/numMesh/mesh.py,
line 469, in _calcGeometry
_CommonMesh._calcGeometry(self)
  File
/usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/meshes/common/mesh.py,
line 613, in _calcGeometry
self._calcFaceNormals()
  File
/usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/meshes/numMesh/mesh2D.py,
line 81, in _calcFaceNormals
orientation = 1 - 2 * (numerix.dot(self.faceNormals,
self.cellDistanceVectors)  0)
  File
/usr/lib/python2.6/dist-packages/FiPy-2.1-py2.6.egg/fipy/tools/numerix.py,
line 841, in dot
return a2.dot(a1)
ValueError: matrices are not aligned

See
http://www.mail-archive.com/numpy-discuss...@scipy.org/msg25306.html
http://docs.scipy.org/doc/numpy/reference/generated/numpy.ndarray.dot.html#numpy.ndarray.dot

As a consequence, numerix dot should change. Something like

if hasattr(a1, 'dot') and not (type(a1) in
(type(MA.array(0)),type(array([0]:
return a1.dot(a2)
elif hasattr(a2, 'rdot') and not (type(a2) in
(type(MA.array(0)),type(array([0]:
return a2.rdot(a1)
elif hasattr(a2, 'dot') and not (type(a2) in
(type(MA.array(0)),type(array([0]:

I suppose.

Greetings,
Benny

Re: ndarray has dot function in numpy trunk

[Benny Malengier]

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

[Benny Malengier]

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

Re: lid driven cavity example

[Benny Malengier]

2010/8/11 Daniel Wheeler daniel.wheel...@gmail.com


 Hi Benny, I've updated the example with your version
 (http://matforge.org/fipy/changeset/3799/). Can I add you name and
 email to the example?


Yes, of course.

I'll use this code the following weeks to determine flow field in a
partially blocked pipe, so should there be remaining issues, I'll send
additional patches.

Greetings,
Benny


 On Mon, Jul 19, 2010 at 6:58 PM, Benny Malengier
 benny.maleng...@gmail.com wrote:
  Hi,
 
  I wanted to test the flow code some more (as was said in the other
 thread,
  difficult to write a good test for the code in viscous limit), and not
  having dolphyn, I decided to see how fipy stacks up for the lid driven
  cavity, Re=1000, which is a well known example with many literature
  comparisons.
 
  The example file and figures are in Ticket URL:
  http://matforge.org/fipy/ticket/306
 
  The literature comparison for a 123x123 grid is not bad, but not stellar
  either:
  http://matforge.org/fipy/attachment/ticket/306/lidcavitylitcmpvx.png
  http://matforge.org/fipy/attachment/ticket/306/lidcavitylitcmpvy.png
 
  I think it would be good to add this example to the flow examples so as
 to
  clearly show fipy users what fipy can do for flow simulations. For my own
  use I only need an approximated flow field to do mass flow, so it seems
  sufficient for my needs.
 
  Perhaps to add in the example is that one can obtain better matching
 values
  with literature for refined parameters, at a heavy computational cost.
 Eg,
  for
  N=243
  pressureRelaxation = 0.8
  velocityRelaxation = 0.6
  sweeps = 3000
  I obtain:
 
 http://matforge.org/fipy/attachment/ticket/306/lidcavitylitcmpvx_N243_sweep3000.png
 
 http://matforge.org/fipy/attachment/ticket/306/lidcavitylitcmpvy_N243_sweep3000.png
 
  As a comparison, it is interesting to look at
 
 http://www.cfd-online.com/Wiki/Sample_code_for_solving_Lid-Driven_cavity_test_%28Re%3D1000%29_-_Fortran_90
  where a 120 grid is used to obtan the results. For a 123 grid, fipy still
  has visible discrepancy, however that code uses a higher order derivative
  for the convective term (HLPA it is called there), perhaps that explains
 it
  Obviously, having such a convective term would be great if it makes such
 a
  difference :-)
 
  Also a result of fluent here:
  http://www.cfd-online.com/Wiki/Lid-driven_cavity_problem on a 32x32
 grid,
  but it is not written what order or method is used or how long the
  computation took.
 
  My guess would be one can obtain better results if one can put the
 velocity
  implicitly in the velocity equation, now the velocity facevariable is
 used,
  which is fixed and updated once in every sweep. I tried that in the code,
  but it is commented out, because the results where bad. Perhaps I do
  something wrong ...
  #xVelocityEq = 2.* xVelocity * PowerLawConvectionTerm(coeff=(1.,0.)) \
  ... #+ yVelocity * PowerLawConvectionTerm(coeff=(0.,1.))
 \
  ... #+ yVelocity.getGrad().dot([0.,1.])*xVelocity \
  .. #- DiffusionTerm(coeff=viscosity) +
 pressure.getGrad().dot([1.,0.])
  #yVelocityEq =  2.* yVelocity * PowerLawConvectionTerm(coeff=(0.,1.))
 \
  ... #+ xVelocity * PowerLawConvectionTerm(coeff=(1.,0.))
 \
  .. #+ xVelocity.getGrad().dot([1.,0.])*yVelocity \
  ... #- DiffusionTerm(coeff=viscosity) +
 pressure.getGrad().dot([0.,1.])
 
  Would be nice if sombody can tweak it to have matching results with the
  literature, but anyway, this test has shown me fipy is adequate for my
  purposes.
  Obviously I wonder if the fully coupled matrix equation Daniel talks
 about
  would not also solve the problem better, however, that fortran code I
 refer
  to works apparently great without such a coupled solver.
 
  Benny
 



 --
 Daniel Wheeler

Re: Hello FiPy community

[Benny Malengier]

2010/9/9 STANLEY, DOUGLAS dmsta...@kent.edu


 For those of you who don't know me by now, my name is Doug Stanley, and
 I work with Laura Bartolo on Matforge.org.

 I just signed up for the mailling list, so I wanted to send an
 introduction note (mainly to make sure I successfully subscribed).


Ok, received well.
If you work at matforge, please make it possible for me to login on matforge
so the bugtickets I make for fipy are correctly attached to me and I don't
have to reenter my email adress on every little edit I make on the bug
tracker (eg http://matforge.org/fipy/ticket/298 ) :-)

Benny

Thanks,
 Doug

Re: variable convection term

[Benny Malengier]

2010/10/13 Daniel Wheeler daniel.wheel...@gmail.com



 On Tue, Oct 12, 2010 at 5:26 PM, BIN ZHANG zhn...@gmail.com wrote:

 Dear Daniel:

 Thanks a lot for your suggestions. Now I'm actually able to solve the
 problem with normal boundary conditions. But I still have one extra
 question, is it possible for me to use complicated boundaries like the one
 shown in the attachment. For the white circle on the left, I would have
 phi=0, and for the white circle on the right, I would have phi=1.

 I tried to define these boundaries using mesh.getInteriorFaces(), but I
 got an error about:  Face list has interior faces

 Is there a way to enforce these complicated boundaries in fipy?


 You can't have interior boundary conditions in FiPy. Cast the boundary
 condition to a volume integral and apply a source term based on location or
 use Benny's suggestion, which can more accurately capture the boundary.


You can however add new terms so as to have internal boundaries :-)
I patch fipy to allow for a diffusion term over an internal membrame. This
works ok.

It would be nice if the design of fipy makes it possible to do this without
patching fipy.
You can see the example here:
http://gitorious.org/microchanit/microchanit/blobs/master/patch/patchfipyrev3871.diff
if you search on diffusiontermmembrane. The problem to do this easily in
fipy is in
fipy/terms/equation.py, with the variable self.orderedKeys

Another way to indicate a class inheriting from DiffusionTerm may not be
added to that class should be found in my opinion. Eg, one can have a class
membervalue (like class.ADDITIONTERM) indicating with what term the class
can be added. So new terms have to explicitly declare to what to add them,
instead of storing this in equation.py. That would allow me having this
custom term in my implementation without requiring to patch fipy to include
it.

PS: some other things in that patch are no longer needed due to the great
speedup in trunk now on adding meshes. Thanks for that ! I do still need a
more elaborate periodic mesh however and my editor pylint check chokes on
combining tabs with 4 spaces in a py file

Benny



 --
 Daniel Wheeler

mem error on adding meshes

[Benny Malengier]

Hi,

I have a problem with mesh addition. Script in attachment leads to a
MemoryError in numpy for me if I use nx,ny,nz=10,80,80, and to a very slow
operation when I use nx,ny,nz=80,80,10. So there seems to be some axis
preference?

Error is:

Traceback (most recent call last):
  File src/testgrid.py, line 52, in module
mesh = mesh1 + mesh2
  File
/usr/lib/python2.6/dist-packages/FiPy-2.2_dev4190-py2.6.egg/fipy/meshes/mesh.py,
line 327, in __add__
return self._concatenatedClass(**self._getAddedMeshValues(other=other))
  File
/usr/lib/python2.6/dist-packages/FiPy-2.2_dev4190-py2.6.egg/fipy/meshes/mesh.py,
line 582, in _getAddedMeshValues
other_XvertexCoords.shape[-1])).swapaxes(0,1)
  File /usr/lib/python2.6/dist-packages/numpy/core/fromnumeric.py, line
863, in resize
a = concatenate( (a,)*n_copies)
MemoryError

Is addition of 3D meshes better avoided, using gmsh instead to make a mesh?
PS: I have some local changes, but they don't interfere with the things this
simple script does.

Benny

Re: mem error on adding meshes

[Benny Malengier]

2011/1/31 Jonathan Guyer gu...@nist.gov



 On Jan 31, 2011, at 11:43 AM, Benny Malengier wrote:

  I have a problem with mesh addition. Script in attachment leads to a
 MemoryError in numpy for me if I use nx,ny,nz=10,80,80, and to a very slow
 operation when I use nx,ny,nz=80,80,10.

 Your script wasn't attached, but I see what you're talking about when I
 concatenated two nx,ny,nz=10,80,80 grids. It got up to 16GiB of VM and 2.7
 GiB of RAM before I got bored and killed it.

 To concatenate meshes, FiPy has to figure out vertex correspondences, and
 because looping is never viable in Python, it does this with full-factorial
 vectorized NumPy calculation (all 72171 vertices of one mesh compared with
 all 72171 vertices of the other), which requires the allocation of about
 1.6e10 floats. Needless to say, this needs a *lot* of memory. Even if it
 succeeds, it's going to thrash VM so much on most systems as to be not worth
 it. This is not very satisfactory, but I don't see a realistic solution.

 I've followed some discussions of distance trees and the like on the SciPy
 list, but they all seem to boil down to more or less what we're doing.
 Probably worth another look, though.


  So there seems to be some axis preference?

 Probably just a fluke. I don't see anything in the code that would favor Z
 over X.


  Is addition of 3D meshes better avoided, using gmsh instead to make a
 mesh?

 FiPy's mesh construction utilities never were (and never will be) very
 sophisticated. So, yes, best to use a tool like Gmsh better suited to the
 task.

  PS: I have some local changes, but they don't interfere with the things
 this simple script does.

 Agreed.


I had a local change previously that introduced a function to add meshes,
where you pass in the vertices of the first mesh and the faces of the second
mesh that where involved. An alternative would be a method in which the
algebraic equation of the surface on which to concatenate is passed.
This worked great on 2D meshes, but the changes in trunk made adding meshes
in 2D just as fast as with this specific function. On 3D reintroducing such
a function might be a solution.
On the other hand, adding uniformgrid3d meshes, one could assume only the
external boundary vertices must be compared.

I'll go for gmsh for now.

Thanks for having a look
Benny

Re: memory limit for irregular mesh ?

[Benny Malengier]

You do

... value=phi(mesh.getCellCenters()))

This is what causes the problem. You can probably work around it by creating
value yourself.
Fipy uses some vectorized algorithms, which works great, but have the
disadvantage that there must be enough memory to allocate the required
arrays.
In this case, by working in chunks to create value, you can work around this
(I believe, did not try anything).

Benny

2011/2/8 Julien Derr julien.d...@gmail.com

 Hi everyone,

 I am dealing with an irregular mesh done between a big circle and a small
 polygone.

 looks like I have memory issues when the polygone becomes more than a few
 hundreds sides. Is that a typical limitation by fipy ? Is there a way to
 deal with big polygonial shapes?

 see error bellow, if you understand it ?

 Traceback (most recent call last):
   File growth.py, line 175, in module
 newphi = CellVariable(name = solution variable,mesh = mesh,
 value=phi(mesh.getCellCenters()))
   File /usr/lib/pymodules/python2.6/fipy/variables/cellVariable.py, line
 197, in __call__
 nearestCellIDs = self.getMesh()_getNearestCellID(points)
   File /usr/lib/pymodules/python2.6/fipy/meshes/common/mesh.py, line 772,
 in _getNearestCellID
 return numerix.argmin(numerix.dot(tmp, tmp, axis = 0), axis=0)
   File /usr/lib/pymodules/python2.6/fipy/tools/numerix.py, line 844, in
 dot
 return sum(a1*a2, axis)
   File /usr/lib/pymodules/python2.6/fipy/tools/numerix.py, line 241, in
 sum
 return NUMERIX.sum(arr, axis)
   File /usr/lib/python2.6/dist-packages/numpy/core/fromnumeric.py, line
 1252, in sum
 return sum(axis, dtype, out)
 MemoryError

 thanks for your help !

 Julien

 PS I am trying to reproduce a typical DLA/saffman taylor problem. so I
 guess the alternative would be to use a simple rectangular lattice, and to
 use a phase parameter to determine what is solid and what is not (like in
 the dendritic solidification example of the fipy help).
  but the issue then is to make some diffusion happen (for another field c)
 only on the space where phi=0. is that possible ?

Re: memory limit for irregular mesh ?

[Benny Malengier]

2011/2/8 Julien Derr julien.d...@gmail.com

 Thanks very much Benny for the explanation, but what do you mean  by
 working  in chunks ?

 I have a variable newphi which is defined on a newmesh and phi the old
 variable which was defined in the original mesh.

 how can I copy phi to newphi by chunk ? In any case the huge array needs
 to be created no ?


The problem is not in the final array, but in the intermediate ones. I see
this in the error:
nearestCellIDs = self.getMesh()_getNearestCellID(points)

So my guess is that every new point has to be compared with all meshpoints
to extract the neareast one. If you do one point at the time, this is
doable, if you 10 points also, ..., but not all points in one go.
In a rectangular regular grid, this is also easy, but not in an unstructured
one.

Benny


 Julien





 On Tue, Feb 8, 2011 at 2:47 PM, Benny Malengier benny.maleng...@gmail.com
  wrote:

 You do

 ... value=phi(mesh.getCellCenters()))

 This is what causes the problem. You can probably work around it by
 creating value yourself.
 Fipy uses some vectorized algorithms, which works great, but have the
 disadvantage that there must be enough memory to allocate the required
 arrays.
 In this case, by working in chunks to create value, you can work around
 this (I believe, did not try anything).

 Benny

 2011/2/8 Julien Derr julien.d...@gmail.com

 Hi everyone,

 I am dealing with an irregular mesh done between a big circle and a small
 polygone.

 looks like I have memory issues when the polygone becomes more than a few
 hundreds sides. Is that a typical limitation by fipy ? Is there a way to
 deal with big polygonial shapes?

 see error bellow, if you understand it ?

 Traceback (most recent call last):
   File growth.py, line 175, in module
 newphi = CellVariable(name = solution variable,mesh = mesh,
 value=phi(mesh.getCellCenters()))
   File /usr/lib/pymodules/python2.6/fipy/variables/cellVariable.py,
 line 197, in __call__
 nearestCellIDs = self.getMesh()_getNearestCellID(points)
   File /usr/lib/pymodules/python2.6/fipy/meshes/common/mesh.py, line
 772, in _getNearestCellID
 return numerix.argmin(numerix.dot(tmp, tmp, axis = 0), axis=0)
   File /usr/lib/pymodules/python2.6/fipy/tools/numerix.py, line 844, in
 dot
 return sum(a1*a2, axis)
   File /usr/lib/pymodules/python2.6/fipy/tools/numerix.py, line 241, in
 sum
 return NUMERIX.sum(arr, axis)
   File /usr/lib/python2.6/dist-packages/numpy/core/fromnumeric.py, line
 1252, in sum
 return sum(axis, dtype, out)
 MemoryError

 thanks for your help !

 Julien

 PS I am trying to reproduce a typical DLA/saffman taylor problem. so I
 guess the alternative would be to use a simple rectangular lattice, and to
 use a phase parameter to determine what is solid and what is not (like in
 the dendritic solidification example of the fipy help).
  but the issue then is to make some diffusion happen (for another field
 c) only on the space where phi=0. is that possible ?

Re: mem error on adding meshes

[Benny Malengier]

2011/2/11 Jonathan Guyer gu...@nist.gov



 On Feb 11, 2011, at 9:43 AM, Benny Malengier wrote:

  I did some tests, and I came to the conclusion I have no idea how the add
 mesh code works. I see in this code 'numerix.resize' and 'numerix.newaxis',
 but these just append with 0's and I see those popping up without being set
 so I fail to understand how these values are actually set.


  Perhaps this code is buggy for 3D?

 There's at least one 3D test that passes, but that doesn't mean there
 aren't problems.

  Hence I conclude I don't understand the code.

 It's possible that nobody does 8^)

  I rewrote the code to what I can understand myself and to what I think it
 is supposed to do, using the repeat function of fipy, which I think is more
 correct that the resize and newaxis combination.

 Thank you!

  I can now add the two 3D meshes without a mem error, and it is actually
 quite fast which I was not expecting as I am using chunks of only 10.

 Interesting. Is that when you compare all vertices or only the exterior
 ones? Both the chunking and the comparison of exterior points are clearly
 good efficiencies, but I'd be interested to know where the primary benefit
 is coming from.


I think the benefit now comes from the chunks, just as in the polygon
problem in the other thread which gave mem error, but with chunks went
without problems. Using an operation manifold decreases the time too of
course, in relation to the number of external indexes that are needed.
My problem was that I added the chunks to the original closeness alg. and it
did not work, I obtained indexes of connecting vertices that where
completely wrong (always between 0 and chunksize).  So I tried to understand
the existing algorithm and failed.

I'll do some extra tests when I have time again, I'm on a symposium at the
moment. The extra nice thing about chunks is that that can be parallelized
if advantageous.

Greetings,
Benny


  If you indicate how the change can be made official, let me know and I
 will do the work. I need direction for that though as I don't want to submit
 patches that have no chance of being integrated.

 That's fair. This change will definitely make it into the code in some
 form, whether we do it or you do it. I'm aware that you've contributed a
 number of other things that haven't made it in, yet. Chalk that up to lack
 of time, not lack of interest.


 As to the underlying closeness algorithm, we'll need to take a look at both
 the old way and your proposal to see which we prefer. We probably won't get
 to it until next week.

Re: simpletrenchsystem.py

[Benny Malengier]

2011/2/18 Daniel Wheeler daniel.wheel...@gmail.com


 On Fri, Feb 18, 2011 at 8:39 AM, Jonathan Guyer gu...@nist.gov wrote:

  By the way, what packages would I need if I attempt to run FiPy on a
 virtual linux system?
 
  http://www.ctcms.nist.gov/fipy/INSTALLATION.html

 Billy, On a clean Ubuntu install the deb should be the easiest method
 for installing http://matforge.org/fipy/downloader/download/release/16.


Inside of windows, virtualization would work, but perhaps also running linux
in windows with andlinux: http://www.andlinux.org/
Not sure, but easy to try.

Benny


 --
 Daniel Wheeler

Re: fipy class.

[Benny Malengier]

I am running pysparse on kubuntu 10.10 from subversion (version 1.2a1).
No errors in the tests.
I do have python-dev installed as I use weave in some projects.

Benny

2011/2/24 Jonathan Guyer gu...@nist.gov



 On Feb 24, 2011, at 11:58 AM, Julien Derr wrote:

  I might be behind a firewall or proxy, at university.
 
  here is the full error I get  : (as I said before there is already
 something which looks obviously wrong like missing {} or integer function
 returning void ?)

 I believe DL_EXPORT is not a function, but a macro, that modifies the
 return value from initspmatrix so that sometimes it might be defined as

 void
 initspmatrix(void)
 {
 
 return ;

 }

 and other times it might be

 something_not_void
 initspmatrix(void)
 {
 
 return ;

 }

 I think what's happening is that your compiler is missing a definition for
 DL_EXPORT, so it is interpreting this code (as you did) as

 DL_EXPORT(void)

 which is legal (even without the {}), but since there's no prototype for
 this function, you get the warning:

  sparse/src/spmatrixmodule.c:359: warning: return type defaults to ‘int’
  sparse/src/spmatrixmodule.c: In function ‘DL_EXPORT’:

 then it tries to interpret

 initspmatrix(void)
 {
 
 return ;

 }

 and the parser is confused by not getting a return type, like void, but
 instead this funny unknown function DL_EXPORT(void), so it gives you:

  sparse/src/spmatrixmodule.c:359: error: expected declaration specifiers
 before ‘initspmatrix’
  sparse/src/spmatrixmodule.c:392: error: expected ‘{’ at end of input



 I don't know whether it's relevant, but in searching on this error, I found

  http://ubuntuforums.org/showthread.php?t=707900

 so you might try installing python-dev.

Re: fipy class.

[Benny Malengier]

2011/3/3 Julien Derr julien.d...@gmail.com

 He re is what I get :

 julien@derr-Precision-T1500:~/Dropbox/diatomes/videos$  python -c 'import
 fipy; print fipy.__version__'
 2.2-dev


If you install via package manager, you install in /usr/, if you install
manual, you install in /usr/local/
So I think it was suggested to you to check if you do not have two instances
of fipy installed at the moment.
If you install manually in ubuntu, to make sure you override packages
installed by the package manager, use

sudo python setup.py install --install-layout=deb

Then installation is in /usr

Benny




 What is the best way to install the up to date version under ubuntu 10.10??




 On Thu, Mar 3, 2011 at 1:43 AM, Daniel Wheeler 
 daniel.wheel...@gmail.comwrote:


 On Wed, Mar 2, 2011 at 12:12 PM, Julien Derr julien.d...@gmail.com
 wrote:
  I guess it is version 2.2
  I think I installed it with the last .deb file for Ubuntu
  In the help, I get this :
 
  FILE
 
 
 /usr/local/lib/python2.6/dist-packages/FiPy-2.2_dev-py2.6.egg/fipy/__init__.py

 The error suggests that you are using an older version of fipy. What does

  python -c 'import fipy; print fipy.__version__'

 return?

 BTW There is no 2.2 deb. The deb may have gone into /usr/ rather than
 /usr/local/. It appears that you are using the deb version because of
 the error. The examples you are running appear to be more recent than
 the version of fipy you are using.

 --
 Daniel Wheeler

Re: fipy class.

[Benny Malengier]

I have
2.2-dev4222

The numer is the svn checkout. Not sure if not working with svn can cause
problems.
I use indeed trunk as in http://www.ctcms.nist.gov/fipy/svn.html so

svn checkout http://matforge.org/svn/fipy/trunk trunk

Note that if you have installed via package manager, you best uninstall via
package manager before doing the install.

Benny

2011/3/4 Julien Derr julien.d...@gmail.com

 I did that, and I still have version 2.2

 julien@derr-Precision-T1500:~/Dropbox/levelset$  python -c 'import fipy;
 print fipy.__version__'
 2.2-dev

 is it the up to date version ? because I still get the same runtime error.


 Julien


 On Fri, Mar 4, 2011 at 10:22 AM, Julien Derr julien.d...@gmail.comwrote:

 Thanks Benny,

 but which version should I install? can you suggest me a link where I can
 update the last version?

 for example, this link would be the up to date version ?

 http://www.matforge.org/fipy/browser/trunk?rev=3488

 I dowload and then I


  sudo python setup.py install --install-layout=deb

 that should be ok ?


 thanks a lot,

 Julien


 On Fri, Mar 4, 2011 at 9:21 AM, Benny Malengier 
 benny.maleng...@gmail.com wrote:



 2011/3/3 Julien Derr julien.d...@gmail.com

 He re is what I get :

 julien@derr-Precision-T1500:~/Dropbox/diatomes/videos$  python -c
 'import fipy; print fipy.__version__'
 2.2-dev


 If you install via package manager, you install in /usr/, if you install
 manual, you install in /usr/local/
 So I think it was suggested to you to check if you do not have two
 instances of fipy installed at the moment.
 If you install manually in ubuntu, to make sure you override packages
 installed by the package manager, use

 sudo python setup.py install --install-layout=deb

 Then installation is in /usr

 Benny




 What is the best way to install the up to date version under ubuntu
 10.10??




 On Thu, Mar 3, 2011 at 1:43 AM, Daniel Wheeler 
 daniel.wheel...@gmail.com wrote:


 On Wed, Mar 2, 2011 at 12:12 PM, Julien Derr julien.d...@gmail.com
 wrote:
  I guess it is version 2.2
  I think I installed it with the last .deb file for Ubuntu
  In the help, I get this :
 
  FILE
 
 
 /usr/local/lib/python2.6/dist-packages/FiPy-2.2_dev-py2.6.egg/fipy/__init__.py

 The error suggests that you are using an older version of fipy. What
 does

  python -c 'import fipy; print fipy.__version__'

 return?

 BTW There is no 2.2 deb. The deb may have gone into /usr/ rather than
 /usr/local/. It appears that you are using the deb version because of
 the error. The examples you are running appear to be more recent than
 the version of fipy you are using.

 --
 Daniel Wheeler

Re: Porting an Electrophisiological model to FiPy

[Benny Malengier]

2011/6/2 Jonathan Guyer gu...@nist.gov



 On Jun 1, 2011, at 10:55 AM, Jeremy Laforet wrote:

 
  I've been looking to use external software to simulate the model of
  uterine muscle we developed in our team.
  FiPy really catch my eye for its high level approach.
  But even after reading the documentation and searching the mailing
  list archive, I'm unsure if FiPy is able to solve this type of problem.
 
  The actual formulation of the model is using 3 variables (per cell):
  - their temporal evolution is described by non-linear coupled ODEs
  (one for each variable)
  - anisotropic diffusion occurs on one of the variables.
 
  Each cell of the mesh would account for a muscle cell, so my variables
  would be CellVariables. I think the ODEs would appear as Source terms.
  But I still don't see how to write my model's equations in the right
  way for FiPy.
 
  Is FiPy able to simulate such things ? If yes, could you point me to
  some examples (regarding multivariables) ?

 As we've just been discussing in

  http://thread.gmane.org/gmane.comp.python.fipy/2208

 FiPy should certainly be able to do this, although we do not have dedicated
 ODE solvers.

 One option is to use the ODE solvers in SciPy for that part of the problem
 and manually assign those solution variables to your FiPy sources.

 The other option, as Biswa has done in his script, is to treat the ODEs as
 degenerate PDEs. A combination of TransientTerm and SourceTerms will solve
 the same ODE at every point in your domain and you can then use that
 solution as the coefficients to your diffusive PDE.

 Let's say you are solving

  \frac{\partial \phi}{\partial t} = \nabla\cdot(m \nabla \phi)

 and

  \frac{d m}{d t} = -\alpha m

 then for the second case, you would write something like

  phi = CellVariable(mesh=mesh, value=phi0, hasOld=True)
  m = CellVariable(mesh=mesh, value=m0, hasOld=True)

  phiEq = TransientTerm() == DiffusionTerm(coeff=m)
  mEq = TransientTerm() == ImplicitSourceTerm(coeff=-alpha)

  for step in range(steps):
  phi.updateOld()
  m.updateOld()
  for sweep in range(sweeps):
  mEq.sweep(var=m, dt=dt)
  phiEq.sweep(var=phi, dt=dt)


 If you were to use SciPy (which might be a very good idea, as it has a
 range of specialized ODE solvers), then I'd be inclined to write

   m = Variable(value=m0)

 and then, whenever you solve the ODE, do something like

   soln = odeint(mFn, m0, ...)

   m.setValue(soln[-1, 0])


Actually, the solvers in scipy start to show their age if you need more
advanced features like preconditioning for the ODEs.
The solvers in scipy have evolved into the C++ Sundials package
https://computation.llnl.gov/casc/sundials/main.html
Python bindings are unfortunately not being updated at the moment
http://sourceforge.net/projects/pysundials/ (stuck on sundials 2.3)
I wrote a high level interface to pysundials which does what I need (which
is a subset of what is possible): http://scikits.appspot.com/odes, advantage
of that is that you don't need to learn how sundials works as it is all
hidden by the interface.

Anyway, odeint is the old lsode solver, if you use ode from scipy you use
vode. If you use pysundials or my package, you use cvode or idas, so you
have something like ode15s in matlab.

I advise you to use an ode solver and not pde, as the ode solvers have
adaptive time stepping and error control, things you don't get in fipy. We
combine ode with fipy, where we solve 1D problems with ode, and use fipy for
higher dimensions.

Benny


 to assign the ODE solution back to the FiPy Variable m.

 I recommend you familiarize yourself with the ODE examples in
 http://www.scipy.org/Cookbook and then ask specific questions about how to
 proceed.

Re: mem error on adding meshes

[Benny Malengier]

2011/9/1 Jonathan Guyer gu...@nist.gov



 On Feb 11, 2011, at 9:43 AM, Benny Malengier wrote:

  Hence I conclude I don't understand the code.
 
  I rewrote the code to what I can understand myself and to what I think it
 is supposed to do, using the repeat function of fipy, which I think is more
 correct that the resize and newaxis combination.
  I also added the chunk trick that was posted some days ago so as to
 prevent to original memoryerror I wanted to avoid. I can now add the two 3D
 meshes without a mem error, and it is actually quite fast which I was not
 expecting as I am using chunks of only 10.
  To reduce memory further, I added a method to pass the vertices over
 which to add, which is used when set, and otherwise exteriorFaces is used
 like before (so the code was already adding only over the external edges).

 I've finally found the time to sit down and both understand the old
 algorithm and what you provided. I've merged your changes to trunk and put
 some comments at http://matforge.org/fipy/ticket/348.

 Many thanks for the contribution!


Great to hear! Looking at the picture you uploaded, my main problem with how
to know the size of the chunks, was tackled thoroughly.

I was on euroscipy last week, and talked about a likewise algorithm to
determine overlap of grains. Gave some slides about FiPy which drew some
attention :-)
Anyway, they advised to do a test with scipy.spatial (pdist function, or
even ckdtree) to see if it is not faster for my use-case. For different
meshes I don't think that would work however (as you don't want to compare
with points of the same mesh). So, if you have a general function,
submitting for inclusion in scipy.spatial is an option that could benefit
many people.

I refractored the code of my patch also as a more 'general' array procedure
I use in another project:
http://gitorious.org/stickproject/stickproject/blobs/master/src/lib/utils/arraycompare.py
Main difference with the patch is:
1/repeat of second array outside of the loop so it is done only once
2/arrays as in scipy.spatial, meaning they are transposed from the ones in
fipy.

I'll look at your final commit and merge your improvements back in my
project, and see if I did not find another optimization myself which could
go back in fipy.

Greetings,
Benny

Re: trilinos issue

[Benny Malengier]

2012/8/28 Daniel Wheeler daniel.wheel...@gmail.com



 On Tue, Aug 28, 2012 at 8:08 AM, Benny Malengier 
 benny.maleng...@gmail.com wrote:

 Hi,

 Installed fipy trunk on a new computer and I seem to have a trilinos
 issue.
 I found the error also here:
 http://matforge.org/fipy/wiki/TrilinosMapPuzzle

 What I do is open a console, import fipy, then CTRL+D to exit it. I
 immediately obtain a warning Teuchos::RCPNode

 Any ideas on what is happening?


 Can you figure out which import is causing this? Try running it in the
 debugger and stepping through import fipy. This might be a little
 laborious, but you should get to the import eventually.  Actually, try
 importing Eperta and make a communicator.

 from PyTrilinos import Epetra
 Epetra.PyComm()

 Does that break?


No.
Using pdb also gives no warning on import fipy. Only when I quit pdb the
warning is given.
Import of PyTrilinos or one of its parts does not give the warning. Only
import of fipy when stopping python.

Benny


 --
 Daniel Wheeler

 ___
 fipy mailing list
 fipy@nist.gov
 http://www.ctcms.nist.gov/fipy
   [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]


___
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]

Re: trilinos issue

[Benny Malengier]

2012/8/28 Daniel Wheeler daniel.wheel...@gmail.com

 On Tue, Aug 28, 2012 at 11:00 AM, Benny Malengier 
 benny.maleng...@gmail.com wrote:



 2012/8/28 Daniel Wheeler daniel.wheel...@gmail.com



 On Tue, Aug 28, 2012 at 8:08 AM, Benny Malengier 
 benny.maleng...@gmail.com wrote:

 Hi,

 Installed fipy trunk on a new computer and I seem to have a trilinos
 issue.
 I found the error also here:
 http://matforge.org/fipy/wiki/TrilinosMapPuzzle

 What I do is open a console, import fipy, then CTRL+D to exit it. I
 immediately obtain a warning Teuchos::RCPNode

 Any ideas on what is happening?


 Can you figure out which import is causing this? Try running it in the
 debugger and stepping through import fipy. This might be a little
 laborious, but you should get to the import eventually.  Actually, try
 importing Eperta and make a communicator.

 from PyTrilinos import Epetra
 Epetra.PyComm()

 Does that break?


 No.
 Using pdb also gives no warning on import fipy. Only when I quit pdb the
 warning is given.
 Import of PyTrilinos or one of its parts does not give the warning. Only
 import of fipy when stopping python.


 I've seen this before sometimes at the end of tests even when the tests
 have run just fine. Do the tests execute okay and can you still use FiPy to
 run your problems?


Yes, that is not the problem. I'm actually not even using Trilinos, in 2.x
series I did not have the required mpi lib installed. This is trunk, on my
other PC I run trunk from after the 3.x release, and that does not show
this issue.
The long output is only annoying at the moment as it is more than a screen,
so I need to scroll for my output. Should I notice something strange, I'll
let you know.  I was just hoping it was something easy to fix.

Benny


 --
 Daniel Wheeler

 ___
 fipy mailing list
 fipy@nist.gov
 http://www.ctcms.nist.gov/fipy
   [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]


___
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]

Re: solving navier-stokes equation in semicircle

[Benny Malengier]

Tanya,

For a lid driven cavity example, see
https://gitorious.org/microchanit/microchanit/blobs/master/patch/patchfipyrev5303.diff
and search for
examples/flow/lidDrivenCavity.py

On a rectangular mesh though. In current fipy is it slower than it was
originally though, and result at end is somewhat off again. But it works :-)

For a semicircle mesh, create your own mesh type in fipy, so create a patch
as I did for this microchanit project, to add the mesh you want. Or create
it in your project.

Benny


2012/12/3 Tanya Gornak err...@gmail.com

 Hello,

 I want to solve lid driven cavity problem in a semicircle. My problem
 is that I need a Cartesian mesh,
 therefore I can not use GMSH to create my geometry.

 How can I create a Cartesian mesh for semicircle for FiPy?

 Thanks in advance.

 --
 Best regards,
 Tatjana
 ___
 fipy mailing list
 fipy@nist.gov
 http://www.ctcms.nist.gov/fipy
   [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]

___
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]

Re: branching grid

[Benny Malengier]

2013/3/25 Kristopher Kuhlman kristopher.kuhl...@gmail.com

 Hello FiPy list,

 I am interested in solving a problem that involves two or more
 overlapping/connected domains.  The same governing equations apply to each
 domain, but the properties are different and I am not sure the best way to
 include geometrical effects.

 In the simplest case, the primary domain is 1D, with one or more secondary
 1D domains extending out from each node, like branches on a tree.  When
 there is one secondary domain, this is almost a 2D grid, except the
 branches are not connected to one another, except through the trunk.

 Is there a way to generate a 2D mesh and change the connectivity of the
 nodes?  Is this something I would have to do with gmsh? Is this even
 something that can be done with gmsh?


You should read up on domain decomposition methods (
http://en.wikipedia.org/wiki/Domain_decomposition_methods ).
Specifically: http://en.wikipedia.org/wiki/Schwarz_alternating_method

So creating two models, each with their own mesh, and an overlap domain,
and apply upscaling/downscaling between the solution is the simplest start.
As FiPy is FVM, basing your scaling on a conserved quantity is the way to
go in my opinion.

Benny


 Kris

 ___
 fipy mailing list
 fipy@nist.gov
 http://www.ctcms.nist.gov/fipy
   [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]


___
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]

Re: Any such thing as an open boundary condition?

[Benny Malengier]

2013/10/1 Richard Edward Gillilan r...@cornell.edu

 Sorry, this is a basic theory question.

 convection-diffusion problem

 I have a pipe containing fluid with dissolved protein of concentration
 phi. I have uniform flow and constant diffusion.
 I would like to make one end of the pipe open so that protein does *not*
 accumulate at the end, but simply flows out and vanishes.

 By open, I mean unconstrained: a boundary segment having no
 constraints on the value of phi or its gradient.

 Is there a way to do this in FiPy?  Does this even make sense?


There are several ways to do this.

If you have only flow, you can use an upwind scheme. That does not require
'right'values so causes unconstrained outflow

For convection diffusion, you can set the diffusion 0 on that edge and use
upwind.
If you mimic an open cup, you can approximate with a constrain of 0 on the
outflow cells. As approx this will often be good.

Then there is the official way in fipy: set a constraint on faceGrad = 0 on
the outflow edge, and set velocity  0 on the same edge. Use an
explicitSourceTerm to mimic correct outflow. So the facegrad constrain
avoids flow due to normal fluxes, the sourceterm removes the correct amount
of material based on velocity.
With the shutdown of USA I don't find the example on the website, but I
used that here:
https://gitorious.org/microchanit/microchanit/source/c2c43969b2c7ceee783f84cfa4b977eeb648fbf4:src/stratflowbeam.py

phi.faceGrad.constrain(0, (zfc  Lval - smallall))

vvel.setValue([[0],[0],[0]], where=outletCells)

exteriorCoeff = FaceVariable(mesh, value=vvel.arithmeticFaceValue, rank=1)
exteriorCoeff.setValue([[0],[0],[0]], where=~outletFaces)


diffeq = ConvectionTerm(coeff=vvel) \
 - DiffusionTerm(mesh, diffcoeff1) \
 + ImplicitSourceTerm(exteriorCoeff.getDivergence())


 Benny
___
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]

viewers not found

[Benny Malengier]

Hi,

If I run from the build directory, I obtain a
  File /home/benny/git/fipy/fipy/viewers/__init__.py, line 133, in Viewer
raise ImportError, No viewers found. Run `python setup.py egg_info` or
similar.

It seems it is needed to do

python setup.py build egg_info

mv FiPy.egg-info build/lib.linux-x86_64-2.7/

where last dir is changed to your actually build dir

After that fipy is usable via PYTHONPATH, eg

PYTHONPATH=/home/benny/git/fipy/build/lib.linux-x86_64-2.7/ python main.py

I don't like to run the install command myself when working from git. As
the egg_info command adds the egg dir to fipy directory, and not build
directory, is it assumed you should use PYTHONPATH from the git dir itself,
so

PYTHONPATH=/home/benny/git/fipy/ python main.py

which works then? I don't like that that creates all the .pyc files to the
git tree.
Perhaps this could be added INSTALLATION.txt ?

Greetings,
Benny
___
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]

Re: viewers not found

[Benny Malengier]

2014-06-19 16:44 GMT+02:00 Daniel Wheeler daniel.wheel...@gmail.com:

 Benny,

 Good to hear from you. Did you try python setup.py develop? This
 allows you to develop on an installed version of a python package. No
 need to mess with PYTHONPATH.

 Cheers,

 Daniel

 On Thu, Jun 19, 2014 at 8:56 AM, Benny Malengier
 benny.maleng...@gmail.com wrote:
  Hi,
 
  If I run from the build directory, I obtain a
File /home/benny/git/fipy/fipy/viewers/__init__.py, line 133, in
 Viewer
  raise ImportError, No viewers found. Run `python setup.py egg_info`
 or
  similar.
 
  It seems it is needed to do
 
  python setup.py build egg_info

 It is a bit odd that the viewers need that, but python setup.py
 develop should deal with any issues like that if you are hacking
 FiPy.


Thanks for the tip, was not aware of it.

Benny


 --
 Daniel Wheeler
 ___
 fipy mailing list
 fipy@nist.gov
 http://www.ctcms.nist.gov/fipy
   [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]

___
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]

question on source term

[Benny Malengier]

Hi,

another question. This time on SourceTerm use. I'm checking an article with
diffusion and reaction. So some species diffuse, others only react (waiting
for diffused species to start). If there is an example with this floating
on the internet, do point it my way!

You then have a coupled set of equations, of which one of the non diffusive
species will have equation like

eqn3 = TransientTerm(var=P0) == ImplicitSourceTerm(-k3*M1, var=P0) +
ImplicitSourceTerm(-k5*M2, var=P0)


eqn4 = TransientTerm(var=P1) == ImplicitSourceTerm(k3*P0, var=M1)


M1 will have another equation that has a diffusionterm.

In eqn3 it is normal to use ImplicitSourceTerm as the rhs has -k3 M1 P0.

In eqn4, we could actually write


eqn4 = TransientTerm(var=P1) == k3*P0*M1


or


eqn4 = TransientTerm(var=P1) == ImplicitSourceTerm(k3*M1, var=P0)


In light that all will be coupled in one equation to solve, will this lead
to different solutions? Or will fipy internally all give this the same
matrix formulation?


Also, in eqn3, the first term in rhs is actually -k3 M1 P0. It seems nicest
if somehow it is guaranteed that values as in eqn4 for this term would be
used. Will this be the case in this formulation?

Perhaps there is a way to do this nicer and introduce a helper variable,
U=M1*P0, so as to have only in eqn3 and eqn4 ImplicitSourceTerm(-k3, var=U)
and ImplicitSourceTerm(k3, var=U) respectively. If so, how to go about to
do this. If I do ImplicitSourceTerm(-k3, var=M1*P0) I get immediately the
error

fipy.terms.SolutionVariableNumberError: Different number of solution
variables and equations.


So, I would need an equation for U, would that be

eqnhelper = ImplicitSourceTerm(1, var=U) == M1*P0

Or am I making things too complicated now.


Thanks!

Benny
___
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]

Re: question on source term

[Benny Malengier]

2014-06-20 16:24 GMT+02:00 Daniel Wheeler daniel.wheel...@gmail.com:

 On Thu, Jun 19, 2014 at 11:53 AM, Benny Malengier
 benny.maleng...@gmail.com wrote:
  Hi,
 
  another question. This time on SourceTerm use. I'm checking an article
 with
  diffusion and reaction. So some species diffuse, others only react
 (waiting
  for diffused species to start). If there is an example with this
 floating on
  the internet, do point it my way!

 Not that I'm aware of.

  You then have a coupled set of equations, of which one of the non
 diffusive
  species will have equation like
 
  eqn3 = TransientTerm(var=P0) == ImplicitSourceTerm(-k3*M1, var=P0) +
  ImplicitSourceTerm(-k5*M2, var=P0)
 
 
  eqn4 = TransientTerm(var=P1) == ImplicitSourceTerm(k3*P0, var=M1)
 
 
  M1 will have another equation that has a diffusionterm.
 
  In eqn3 it is normal to use ImplicitSourceTerm as the rhs has -k3 M1 P0.

 Yes, but the right splitting for -k3 * M1 * P0 is probably

k3 * M1 * P0 - ImplicitSourceTerm(k3 * M1, var=P0) -
 ImplicitSourceTerm(k3 * P0, var=M1)

  In eqn4, we could actually write
 
 
  eqn4 = TransientTerm(var=P1) == k3*P0*M1
 
 
  or
 
 
  eqn4 = TransientTerm(var=P1) == ImplicitSourceTerm(k3*M1, var=P0)
 
 
  In light that all will be coupled in one equation to solve, will this
 lead
  to different solutions?

 It shouldn't assuming that there isn't an instability. Eventually,
 they should converge to the same result, but not at the the same rate.

  Or will fipy internally all give this the same
  matrix formulation?

 It certainly won't give the same matrix formulation for different
 implicit / explicit choices. User needs to be aware of what's going
 on.

  Also, in eqn3, the first term in rhs is actually -k3 M1 P0. It seems
 nicest
  if somehow it is guaranteed that values as in eqn4 for this term would be
  used. Will this be the case in this formulation?

 Don't understand the question fully. Do you mean that it would be nice
 to be using the latest value of M1? This won't happen as M1 is
 explicit in Equation 3. Either P0 is explicit or M1 will be
 explicit in Equation 3 (or both). There is no way to avoid this.

  Perhaps there is a way to do this nicer and introduce a helper variable,
  U=M1*P0, so as to have only in eqn3 and eqn4 ImplicitSourceTerm(-k3,
 var=U)
  and ImplicitSourceTerm(k3, var=U) respectively. If so, how to go about
 to do
  this. If I do ImplicitSourceTerm(-k3, var=M1*P0) I get immediately the
 error
 
  fipy.terms.SolutionVariableNumberError: Different number of solution
  variables and equations.

 The helper variable won't buy you anything. Use a Taylor expansion to
 make the correct explicit / implicit choice

 S = Sc + var1 * dS / dvar1 + var2 * dS / dvar2

 if S is the source term. The other choice would be to do full Newton
 iteration.

  So, I would need an equation for U, would that be
 
  eqnhelper = ImplicitSourceTerm(1, var=U) == M1*P0
 
  Or am I making things too complicated now.

 This doesn't help since you still have an explicit representation for
 M1 and P0 in one of the equations.


Thanks for the pointers, I'll try some things. My FiPy knowledge is slowly
getting back.

My main question seems to have come down on how intelligent the coupling
mechanism in fipy is as opposed to using the old sweep and updating values
when finished. If I understand you correctly, only the var option of
ImplicitSourceTerm comes into play (
http://www.ctcms.nist.gov/fipy/examples/diffusion/generated/examples.diffusion.coupled.html
) so the other var present are explicit, also after coupling. Seems the
logical thing.

So, next question would be, can I use the nicer new notation suitable for
coupling, and nevertheless sweep the coupled equation? But sweep requires a
var option, so that seems not possible on the coupled equation, but perhaps
is still possible on the seperate equations (would be nice if the coupled
equation var could be passed in some way ...). So I could envision, doing
one solve on the coupled equation, then doing sweep equation per equation,
and continuing that till low residuals are obtained.

If no sweeping is used, I would expect it best to take equal parts explicit
and implicit. So not as you say

   k3 * M1 * P0 - ImplicitSourceTerm(k3 * M1, var=P0) -
ImplicitSourceTerm(k3 * P0, var=M1)

but

  - 1/2 *ImplicitSourceTerm(k3 * M1, var=P0) - 1/2*ImplicitSourceTerm(k3 *
P0, var=M1)

or if a fully explicit term is used, then 1/3 of three terms.
If sweeping of equations written like that is supported, then sweeping this
should go to full implicit.

Anyway, my code is working already, so I can try different formulations out
myself and see how much they result in different solutions.

In case you wonder what I try to reproduce, see figures and equation in

http://rspb.royalsocietypublishing.org/content/271/1548/1565

It's nice that after some hours with fipy you have a fully working script
:-). But then the nagging question of how correct everything is pops up off

Re: pickle/dump

[Benny Malengier]

2014-08-21 22:17 GMT+02:00 Daniel Wheeler daniel.wheel...@gmail.com:

 On Wed, Aug 20, 2014 at 6:12 PM, Seufzer, William J. (LARC-D307) 
 bill.seuf...@nasa.gov wrote:

 Thanks Dan,

 This works... but I also made the change to nonUniformGrid3D.py as well.
 I noticed the simple edits, made them by hand, and re-installed FiPY in
 both environments.


 I missed that. Thanks for pointing it out.



 Just a note (mainly for anyone else who runs into this):

 Any data files created with the old code will still not be readable with
 this code update in the non-Trilinos environment. Both environments need to
 have the updated code.

 Hope I stated that clearly!



 In my experience, pickling doesn't work very well for long term or medium
 term data storage. For medium/short term storage (life time of a project) I
 always just save the numpy arrays (not with pickle, but with Pandas or
 numpy.savetxt), but not the FiPy objects to avoid the kinds of problems
 that you're having. I don't currently have a good solution for long term
 data storage.


For long term storage, specific serialize and deserialize methods are
needed. In text format for very long term (over OS and arch boundaries)
For example, boost serialize in C++ classes (
http://www.boost.org/doc/libs/1_56_0/libs/serialization/doc/index.html ).
Easy to add in C++ to a class.
For python, working on top of json
https://docs.python.org/2/library/json.html seems like the way to go.

Benny


 --
 Daniel Wheeler

 ___
 fipy mailing list
 fipy@nist.gov
 http://www.ctcms.nist.gov/fipy
   [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]


___
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]

Re: fipy python 2.7

[Benny Malengier]

I suppose the normal way adding  python=2.7
to the conda arguments was tried and did not work?

2017-11-08 23:01 GMT+01:00 James Pringle :

> Dear all -- (but mainly Daniel Wheeler, I guess)
>
>I am in the midst of finishing up a paper, but am trying to transition
> to a new workstation. I have always installed fipy with
>
> conda create --name  --channel guyer --channel conda-forge fipy 
> nomkl
>
>
> and now, under anaconda, it installs fipy 3.1.3 with python 3.6.3. Is
> there anyway to use conda to install it under python 2.7? I have nothing
> against upgrading to python 3.6 -- but not as a finish a manuscript
>
> This is not urgent -- I have my old setup. But if there was any easy way
> to use conda to install a new copy of fipy under python 2.7 until the paper
> is out the door, that would be great.
>
> Thanks,
> Jamie
>
> ___
> fipy mailing list
> fipy@nist.gov
> http://www.ctcms.nist.gov/fipy
>   [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
>
>
___
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]