Re: nonlinear transient coefficient

[Guyer, Jonathan E. Dr. (Fed) via fipy]

P/S will indeed be explicit, as will dh/dx.dS/dx, but its behavior may be 
better. It’s worth trying.

You may just be stuck with very small time steps.

On May 26, 2020, at 4:16 AM, Urzainqui Aramburu Iñaki (Luke) 
mailto:inaki.urzain...@luke.fi>> wrote:

Dear Jonathan,

Thanks for your quick reply!

I considered the option you mention as well, but the source term (what I called 
P in the PDE) would then become P/S. Wouldn’t that be restricted to backward 
Euler as well?

And thanks for the advice: I double-checked and S(h) does sit outside the time 
derivative.

More questions might be coming in the near future. Thanks for your answer and 
for developing FiPy!

Best,

Iñaki

From: fipy-boun...@nist.gov<mailto:fipy-boun...@nist.gov> 
mailto:fipy-boun...@nist.gov>> On Behalf Of Guyer, 
Jonathan E. Dr. (Fed) via fipy
Sent: lauantai 23. toukokuuta 2020 19.08
To: FIPY mailto:FIPY@nist.gov>>
Subject: Re: nonlinear transient coefficient

You might try dividing through by S(h) and applying the chain rule:

(1/S(h)) d/dx(T(h) dh/dx) = d/dx((T(h) / S(h)) dh/dx) + (T(h) / S(h)^2) dh/dx . 
dS(h)/dx

The second term on the RHS still doesn’t have very efficient representation in 
FiPy, either, but it’s at least not limited to first order backward Euler.


Frankly, I would check that S(h) really sits outside the time derivative. The 
derivations I’ve seen that look like that usually (and often quietly) assume 
the coefficient (e.g., heat capacity) is uniform.


On May 22, 2020, at 4:41 AM, Urzainqui Aramburu Iñaki (Luke) 
mailto:inaki.urzain...@luke.fi>> wrote:

Dear developers,

I am trying to solve the following diffusion PDE with fipy:

S(h) * dh/dt = d/dx(T(h)*dh/dx) + P

S and T are both nonlinear functions of h. (There is no closed analytical form 
to express them, but they could be parameterized somehow, e.g., S(h) = 
a*exp(b*h))

Reading the docs and following the examples, it seems to me that 
TransientTerm(coeff=S) would not do the job in FiPy, since this corresponds to 
d(S*h)/dt.
One idea is to write the left hand side of the equation above as:

S*dh/dt = d(S*h)/dt – h*dS/dt.

Then, the equation would look like so:

d(S*h)/dt = d/dx(T(h)*dh/dx) + P + h*dS/dt

And this new version of the equation would be implemented as follows:

TransientTerm(coeff=S) == DiffusionTerm(coeff=T) + P + ImplicitSourceTerm((S – 
S.old)/dt)

However, this new term makes the equation very unstable. Is this the right way 
to approach this problem in FiPy? Are there any alternatives?

Thanks for your help. Best regards,

Iñaki



___
fipy mailing list
fipy@nist.gov<mailto: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: nonlinear transient coefficient

[Guyer, Jonathan E. Dr. (Fed) via fipy]

You might try dividing through by S(h) and applying the chain rule:

(1/S(h)) d/dx(T(h) dh/dx) = d/dx((T(h) / S(h)) dh/dx) + (T(h) / S(h)^2) dh/dx . 
dS(h)/dx

The second term on the RHS still doesn’t have very efficient representation in 
FiPy, either, but it’s at least not limited to first order backward Euler.


Frankly, I would check that S(h) really sits outside the time derivative. The 
derivations I’ve seen that look like that usually (and often quietly) assume 
the coefficient (e.g., heat capacity) is uniform.

On May 22, 2020, at 4:41 AM, Urzainqui Aramburu Iñaki (Luke) 
mailto:inaki.urzain...@luke.fi>> wrote:

Dear developers,

I am trying to solve the following diffusion PDE with fipy:

S(h) * dh/dt = d/dx(T(h)*dh/dx) + P

S and T are both nonlinear functions of h. (There is no closed analytical form 
to express them, but they could be parameterized somehow, e.g., S(h) = 
a*exp(b*h))

Reading the docs and following the examples, it seems to me that 
TransientTerm(coeff=S) would not do the job in FiPy, since this corresponds to 
d(S*h)/dt.
One idea is to write the left hand side of the equation above as:

S*dh/dt = d(S*h)/dt – h*dS/dt.

Then, the equation would look like so:

d(S*h)/dt = d/dx(T(h)*dh/dx) + P + h*dS/dt

And this new version of the equation would be implemented as follows:

TransientTerm(coeff=S) == DiffusionTerm(coeff=T) + P + ImplicitSourceTerm((S – 
S.old)/dt)

However, this new term makes the equation very unstable. Is this the right way 
to approach this problem in FiPy? Are there any alternatives?

Thanks for your help. Best regards,

Iñaki



___
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: Setting up boundary conditions

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Setting mu_p_1, mu_n_1, Dp_1, and Dn_1 to zero at the faces of the insulating 
cells should prevent any flux of charge into those cells. Those coefficients 
should be set as FaceVariables and assigned to coeff= in the Terms, rather than 
multiplying outside the Term.


> On Mar 30, 2020, at 3:20 PM, Justin Pothoof  wrote:
> 
> I'm working on drift-diffusion simulation and am having difficulties setting 
> up boundary conditions to describe my system. I have the bare bones of the 
> system attached in a .txt file.
> 
> I have the potential on the left constrained to 9 and on the right to 0 to 
> reflect applying a 9V bias to the system. Now, what I want to include is 
> essentially an insulating layer to the left and right side.. let's say 10 
> mesh cells on both sides. So, I don't want any positive or negative charges 
> to start in those cells, or be able to flow into those cells. Is that 
> possible? I've tried extracting the mesh face values and constraining Pion 
> and Nion to be zero in those cells, but that didn't seem to run properly. Any 
> advice?
> 
> Justin Pothoof
> The University of Washington - Department of Chemistry
> Pre-Candidacy PhD Student
> Ginger Group
> ___
> 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: Axes scales for 2D mesh

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Welcome to FiPy, Davide.

The Matplotlib viewers accept a `figaspect` argument, so in your case, you 
would write:

viewer = Matplotlib2DViewer(vars=(phi,), figaspect=1.)

On Mar 23, 2020, at 12:26 PM, Davide Cretti 
mailto:davide.cre...@gmail.com>> wrote:

Dear developers,

I am new to fipy and at the moment I am trying to implement it for a 2D 
convection-diffusion problem. The package is great and rather easy to use. 
Nonetheless, I have an issue that might sound trivial to you. The issue regards 
the plot of the 2D mesh. When I implement a value for the length of the x-axis 
that is much smaller than the value for the length of the y-axis, the viewer 
does not scale the axes to obtain a more or less "square" plot, but displays a 
very squashed plot instead. I was wondering if you could give me a hand in 
solving this problem. I added a simplified version of the code below.

Thanks in advance.

Kind regards,

Davide Cretti

N=100
Lx=0.1
Ly=1

dt=1
steps=1

alpha=1

mesh = Grid2D(dx=Lx/N, dy=Ly/N, nx=N, ny=N)
phi = CellVariable(mesh=mesh, value=1)

eq = TransientTerm() == DiffusionTerm(coeff=alpha)

viewer = Viewer(phi, mesh)



for steps in range(steps):
eq.solve(var = phi, dt=dt)
viewer.plot()

if __name__ == '__main__':
input()
___
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: Help with FiPy

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Teaching Python is well beyond the scope of what we're in a position to do. 
There are many excellent online resources for this.

On Mar 13, 2020, at 10:16 AM, Abderrezak BOUZIANE 
mailto:a.bouziane@gmail.com>> wrote:

I want to make a CFD-DEM coupled model. To do this I want to use itasca PFC 3D 
for DEM simulation and python for CFD simulation. My problem is that I've never 
used python. That's why I want to start programming with fipy at the moment, so 
I need first of all support to master the programming language.
I hope to find some help from you. And I remain at your disposal for further 
information.
Best regards

Le ven. 13 mars 2020 à 14:56, Guyer, Jonathan E. Dr. (Fed) via fipy 
mailto:fipy@nist.gov>> a écrit :
You're going to have to give us more to work with. What have you tried? Where 
are you stuck?

On Mar 11, 2020, at 11:23 AM, Abderrezak BOUZIANE 
mailto:a.bouziane@gmail.com>> wrote:

Hi Everyone, I want to use FiPy to solve Darcy's flow equation, can you give me 
some support to speed me up in the learning process.
Thank you in advance.

--
[https://docs.google.com/uc?export=download=1zrSgTcN0o9WtDJMqlbmKCO2OysRkO2mE=0B8Lx-4m_Yht4TlliVDRqbVlXTlZNMzNuSEsyNkF6T0hYd1Q0PQ]
[https://mailfoogae.appspot.com/t?sender=aYS5ib3V6aWFuZS5kb2NAZ21haWwuY29t=zerocontent=aed074ba-17f8-4352-8609-7c67e3f09ff8]ᐧ
___
fipy mailing list
fipy@nist.gov<mailto: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<mailto:fipy@nist.gov>
http://www.ctcms.nist.gov/fipy
  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]


--
[https://docs.google.com/uc?export=download=1zrSgTcN0o9WtDJMqlbmKCO2OysRkO2mE=0B8Lx-4m_Yht4TlliVDRqbVlXTlZNMzNuSEsyNkF6T0hYd1Q0PQ]

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

Re: Help with FiPy

[Guyer, Jonathan E. Dr. (Fed) via fipy]

You're going to have to give us more to work with. What have you tried? Where 
are you stuck?

On Mar 11, 2020, at 11:23 AM, Abderrezak BOUZIANE 
mailto:a.bouziane@gmail.com>> wrote:

Hi Everyone, I want to use FiPy to solve Darcy's flow equation, can you give me 
some support to speed me up in the learning process.
Thank you in advance.

--
[https://docs.google.com/uc?export=download=1zrSgTcN0o9WtDJMqlbmKCO2OysRkO2mE=0B8Lx-4m_Yht4TlliVDRqbVlXTlZNMzNuSEsyNkF6T0hYd1Q0PQ]
[https://mailfoogae.appspot.com/t?sender=aYS5ib3V6aWFuZS5kb2NAZ21haWwuY29t=zerocontent=aed074ba-17f8-4352-8609-7c67e3f09ff8]ᐧ
___
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: Charge dynamics and Neumann boundary conditions

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Yuranan -

Question: As you can see, shouldn't the value of g be set to -v on the left and 
+v on the right? The present code gives the solution of phi that is not 
symmetric. I expect phi to have some symmetric behavior near the left and right 
boundary.

A: I think you are probably right about the signs. As I recall, I was working 
through with a right-ward facing normal, so that the signs came out the same, 
but it should probably be an outward facing normal


Questions: How do we treat the boundary condition on the varational terms? 
Especially, the Robin boundary conditions on this term.

I think given a Robin condition:

$$ \hat{n}\cdot\left(\vec{a}\phi + b\nabla \phi\right) = g $$

that the boundary condition on the variation would be another Robin condition:

$$ \hat{n}\cdot\left(\vec{a}\delts\phi + b\nabla \delta\phi\right) = 0 $$

- Jon


> On Mar 7, 2020, at 12:08 AM, Yuranan Hanlumyuang  wrote:
> 
> Hi FiPy team,
> 
> I have a few subsequent questions about the (1) the Robin boundary condition, 
> and (2) the Newton-Method implementation. I listed the questions in 
> 
> https://bit.ly/2TI8jlW
> 
> along with some relevant equations. The questions concern (1) the values of 
> ‘g’ in the Robin boundary conditions, and (2) the boundary condition for the 
> variational of parameters in the Newton method.  I would be greatly 
> appreciated any guidance you may offer regarding other points as well. 
> 
> Best,
> Yuranan
> 
> 
> 
> 
> 
> 
>> On Feb 25, 2020, at 10:32 PM, Guyer, Jonathan E. Dr. (Fed) via fipy 
>>  wrote:
>> 
>> Sorry. I never said what the few things were.
>> 
>> FiPy has no-flux boundary conditions by default. It's a characteristic of 
>> the finite-volume method. So, your Eqs. (3) are satisfied without applying 
>> any constraints. 
>> 
>> Eqs. (4) and (5) are a [Robin 
>> condition](https://www.ctcms.nist.gov/fipy/documentation/USAGE.html#applying-robin-boundary-conditions).
>>  I've modified your notebook to apply a Robin condition on \phi.
>> 
>> The singular matrix arises because \rho is initialized to zero, which means 
>> the coefficient matrix for DiffusionTerm(coeff=Drho, var=phi) is initially 
>> zero. The total matrix is still block diagonal, so I don't really understand 
>> why this gives a singular matrix, but initializing \rho to something other 
>> than zero seems to solve that problem. Unfortunately, as I said before, it 
>> still diverges.
>> 
>> - Jon
>> 
>>> On Feb 25, 2020, at 10:04 AM, Guyer, Jonathan E. Dr. (Fed) via fipy 
>>>  wrote:
>>> 
>>> Yuranan -
>>> 
>>> There are a few things going on here.
>>> 
>>> I've modified your notebook and posted it at 
>>> https://github.com/guyer/sharing-github/blob/master/ion-transport-diagnosis.ipynb.
>>> 
>>> The singular matrix has gone away, but the solution diverges. In general, I 
>>> find the drift-diffusion equations pretty challenging to solve. 
>>> Newton-Raphson iterations are almost always called for and under-relaxation 
>>> or other damping can be needed, too.
>>> 
>>> - Jon
>>> 
>>>> On Feb 24, 2020, at 7:11 PM, Yuranan Hanlumyuang  wrote:
>>>> 
>>>> Dear the FiPy Team,
>>>> 
>>>> We are trying to solve the coupled equations in the paper titled 
>>>> "Diffuse-charge dynamics in electrochemical systems" by Bazant, Thornton 
>>>> and Ajdari using FiPy.  I am posting a copy of the python code and the 
>>>> equations here 
>>>> https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbit.ly%2F32fIA8adata=02%7C01%7Cjonathan.guyer%40nist.gov%7C18104f76caae4eec145e08d7ba042d06%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637182399411065840sdata=h%2FJN%2BFiGcsAGDTNclX%2FqQImXHUgA3%2Fc5LEb5P0F8PTQ%3Dreserved=0
>>>> 
>>>> The example of Binary_Electrolytes posted by Prof. Guyer has been followed 
>>>> closely. However, we keep encountering the errors of 
>>>> self.factorizeFnc(*args, **kwargs) with the RuntimeError: Factor is 
>>>> exactly singular. We were unable to diagnose if there is anything wrong 
>>>> with the way we set (1) the boundary conditions, or (2) the coupled 
>>>> equations. 
>>>> 
>>>> We tried to use “eqns.solve()” as well, but still it didn’t work.  I would 
>>>> appreciate any guidance that you can offer.   
>>>> 
>>>> The code in the text format is listed below: 
>>>> from fipy import *
>>>> 
>>>> m = Grid1D(nx=100,Lx=2.0)
>>>> 
&

Re: Implementation of Dirichlet Boundary Condition

[Guyer, Jonathan E. Dr. (Fed) via fipy]

The change you propose is inconsistent with the convection scheme, as evidenced 
by the large number of test failures that result. 

Is there a problem for which FiPy fails to produce the correct answer?

If there is, then any solution to that problem must work for arbitrary 
dimensions, arbitrary geometries, and arbitrary convection schemes. We will not 
be making any changes that are only valid for central differencing in 1D.

> On Mar 10, 2020, at 12:59 PM, Alexander Tismer 
>  wrote:
> 
> Dear Jonathan,
> 
> I also sent a pull request in github with a change to treat the 
> boundaries correctly.
> Hope this help.
> 
> Warm regards
> Alex
> 
> Am 08.03.20 um 11:13 schrieb Alexander Tismer:
>> Dear Jonathan,
>> 
>> many thanks for your quick reply.
>> 
>> I figured out that the convective flux crossing the left side of the
>> element W is in your equation
>> 
>> - rho * v * (phi_W + phi(X=0))/2
>> 
>> and in my equation
>> 
>> - rho * v * phi(X=0)
>> 
>> That is the difference. Why is it necessary to interpolate the value of
>> phi at the left side between phi_W and phi(X=0)? The value of phi is
>> known at this position, because it is the boundary condition.
>> 
>> Warm regards,
>> Alex
>> Am 06.03.20 um 21:30 schrieb Guyer, Jonathan E. Dr. (Fed) via fipy:
>>> My guess is that you got the sign of the outward-facing normal wrong
>>> somewhere. I posted my derivation to
>>> https://gist.github.com/guyer/3b77bbf32d90ef314754f0d76a7e04cc.
>>> 
>>> 
>>>> On Mar 6, 2020, at 4:09 AM, Alexander Tismer
>>>> >>> <mailto:alexander.tis...@ihs.uni-stuttgart.de>> wrote:
>>>> 
>>>> Dear Users,
>>>> 
>>>> my question concerns the implementation of the boundary conditions in
>>>> FiPy.
>>>> I would like to solve a 1D Conv-Diff-Equation with 3 control volumes
>>>> using CentralDifferenceConvectionTerm and DiffusionTerm of FiPy.
>>>> 
>>>> For me, it is not clear why the first row of the matrix of the linear
>>>> equation system is
>>>>> 9.00  -2.50  ---
>>>> and the right hand side is
>>>>> 6.5
>>>> 
>>>> The case is the following. Each control volume (W, C and E) has the
>>>> length 1/3. All coefficients (gamma, u, rho) in the equation is set to 1:
>>>> 
>>>>o---> x
>>>>|-D=1/3-|-D=1/3-|-D=1/3-|
>>>>   x=0 x=1
>>>> phi=1   phi=0
>>>>v   v
>>>>+---+---+---+
>>>>|   W   |   C   |   E  |
>>>>o---x---o---x---o---x---o
>>>>|   |   |   |
>>>>+---+---+---+
>>>> 
>>>> If I discretize the equation in the first control volume (W), I get
>>>> for the matrix row
>>>>> 10.00  -2.50  ---
>>>> and for the right hand side
>>>>> 7.0
>>>> 
>>>> So this is a little bit different from FiPy. Is there any mistake from
>>>> my side?
>>>> 
>>>> Please find attached my notes on how calculating my matrix
>>>> coefficients (fipy_0.png) and my python script for fipy (fipy.py).
>>>> 
>>>> Warm regards,
>>>> Alex
>>>> ___
>>>> fipy mailing list
>>>> fipy@nist.gov <mailto: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 ]
>>> 
>> 
> 
> -- 
> Alexander Tismer
> 
> Institut für Strömungsmechanik
> und Hydraulische Strömungsmaschinen
> Universität Stuttgart
> Pfaffenwaldring 10
> 70550 Stuttgart
> 
> Tel.:   +49 (0) 711 / 685 63007
> Fax:+49 (0) 711 / 685 63255
> eMail: alexander.tis...@ihs.uni-stuttgart.de
> https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ihs.uni-stuttgart.dedata=02%7C01%7Cjonathan.guyer%40nist.gov%7C6efb1a8d58b946dad65b08d7c5149ec4%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637194564665197918sdata=1zJ1urkF4B432%2BJGhVrVSW7tghanW3Nz3aGBPwUKjZ4%3Dreserved=0
> ___
> 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: Implementation of Dirichlet Boundary Condition

[Guyer, Jonathan E. Dr. (Fed) via fipy]

My guess is that you got the sign of the outward-facing normal wrong somewhere. 
I posted my derivation to 
https://gist.github.com/guyer/3b77bbf32d90ef314754f0d76a7e04cc.


On Mar 6, 2020, at 4:09 AM, Alexander Tismer 
mailto:alexander.tis...@ihs.uni-stuttgart.de>>
 wrote:

Dear Users,

my question concerns the implementation of the boundary conditions in FiPy.
I would like to solve a 1D Conv-Diff-Equation with 3 control volumes using 
CentralDifferenceConvectionTerm and DiffusionTerm of FiPy.

For me, it is not clear why the first row of the matrix of the linear equation 
system is
> 9.00  -2.50  ---
and the right hand side is
> 6.5

The case is the following. Each control volume (W, C and E) has the length 1/3. 
All coefficients (gamma, u, rho) in the equation is set to 1:

   o---> x
   |-D=1/3-|-D=1/3-|-D=1/3-|
  x=0 x=1
phi=1   phi=0
   v   v
   +---+---+---+
   |   W   |   C   |   E  |
   o---x---o---x---o---x---o
   |   |   |   |
   +---+---+---+

If I discretize the equation in the first control volume (W), I get for the 
matrix row
> 10.00  -2.50  ---
and for the right hand side
> 7.0

So this is a little bit different from FiPy. Is there any mistake from my side?

Please find attached my notes on how calculating my matrix coefficients 
(fipy_0.png) and my python script for fipy (fipy.py).

Warm regards,
Alex
___
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: Charge dynamics and Neumann boundary conditions

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Sorry. I never said what the few things were.

FiPy has no-flux boundary conditions by default. It's a characteristic of the 
finite-volume method. So, your Eqs. (3) are satisfied without applying any 
constraints. 

Eqs. (4) and (5) are a [Robin 
condition](https://www.ctcms.nist.gov/fipy/documentation/USAGE.html#applying-robin-boundary-conditions).
 I've modified your notebook to apply a Robin condition on \phi.

The singular matrix arises because \rho is initialized to zero, which means the 
coefficient matrix for DiffusionTerm(coeff=Drho, var=phi) is initially zero. 
The total matrix is still block diagonal, so I don't really understand why this 
gives a singular matrix, but initializing \rho to something other than zero 
seems to solve that problem. Unfortunately, as I said before, it still diverges.

- Jon

> On Feb 25, 2020, at 10:04 AM, Guyer, Jonathan E. Dr. (Fed) via fipy 
>  wrote:
> 
> Yuranan -
> 
> There are a few things going on here.
> 
> I've modified your notebook and posted it at 
> https://github.com/guyer/sharing-github/blob/master/ion-transport-diagnosis.ipynb.
> 
> The singular matrix has gone away, but the solution diverges. In general, I 
> find the drift-diffusion equations pretty challenging to solve. 
> Newton-Raphson iterations are almost always called for and under-relaxation 
> or other damping can be needed, too.
> 
> - Jon
> 
>> On Feb 24, 2020, at 7:11 PM, Yuranan Hanlumyuang  wrote:
>> 
>> Dear the FiPy Team,
>> 
>> We are trying to solve the coupled equations in the paper titled 
>> "Diffuse-charge dynamics in electrochemical systems" by Bazant, Thornton and 
>> Ajdari using FiPy.  I am posting a copy of the python code and the equations 
>> here 
>> https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbit.ly%2F32fIA8adata=02%7C01%7Cjonathan.guyer%40nist.gov%7C18104f76caae4eec145e08d7ba042d06%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637182399411065840sdata=h%2FJN%2BFiGcsAGDTNclX%2FqQImXHUgA3%2Fc5LEb5P0F8PTQ%3Dreserved=0
>> 
>> The example of Binary_Electrolytes posted by Prof. Guyer has been followed 
>> closely. However, we keep encountering the errors of 
>> self.factorizeFnc(*args, **kwargs) with the RuntimeError: Factor is exactly 
>> singular. We were unable to diagnose if there is anything wrong with the way 
>> we set (1) the boundary conditions, or (2) the coupled equations. 
>> 
>> We tried to use “eqns.solve()” as well, but still it didn’t work.  I would 
>> appreciate any guidance that you can offer.   
>> 
>> The code in the text format is listed below: 
>> from fipy import *
>> 
>> m = Grid1D(nx=100,Lx=2.0)
>> 
>> v = 1
>> epsilon= 0.05
>> delta = 0.1
>> x = m.cellCenters[0]
>> 
>> 
>> ##Initial conditions
>> c = CellVariable(name="c", mesh=m , value=1.0, hasOld=True)
>> 
>> rho = CellVariable(name="rho", mesh=m , value=0.0, hasOld=True)
>> 
>> phi = CellVariable(name="phi",mesh=m, hasOld=True)
>> phi.setValue(v*(x-1), where=m.cellCenters)
>> 
>> #vi =Viewer((phi, c, rho),datamin=-1.1, datamax=1.1)
>> #vi.plot()
>> 
>> 
>> ##Boundary conditions
>> c.faceGrad.constrain(-rho.faceValue*phi.faceGrad, where=m.facesLeft)
>> c.faceGrad.constrain(-rho.faceValue*phi.faceGrad, where=m.facesRight)
>> 
>> rho.faceGrad.constrain(-c.faceValue*phi.faceGrad, where=m.facesLeft)
>> rho.faceGrad.constrain(-c.faceValue*phi.faceGrad, where=m.facesRight)
>> 
>> 
>> phi.faceGrad.constrain((phi.faceValue+v)/(epsilon*delta), where=m.facesLeft)
>> phi.faceGrad.constrain((phi.faceValue-v)/(-epsilon*delta), 
>> where=m.facesRight)
>> 
>> 
>> ##Equations
>> 
>> Drho = epsilon*rho
>> Dc   = epsilon*c
>> 
>> eq1 = TransientTerm(var=c) == DiffusionTerm(coeff=epsilon, var=c) 
>> +DiffusionTerm(coeff=Drho, var=phi)
>> eq2 = TransientTerm(var=rho) == DiffusionTerm(coeff=epsilon, var=rho) 
>> +DiffusionTerm(coeff=Dc, var=phi)
>> eq3 = DiffusionTerm(coeff=epsilon*epsilon, 
>> var=phi)+ImplicitSourceTerm(coeff=1.0, var=rho) == 0
>> eqns = eq1 & eq2 & eq3 
>> 
>> 
>> ##Solve
>> #vi =Viewer((phi, c, rho),datamin=-1.1, datamax=1.1)
>> #from builtins import range
>> 
>> res = 1e+10
>> restol= 1e-13
>> 
>> for t in range(100):
>>c.updateOld()
>>rho.updateOld()
>>phi.updateOld()
>>while res > restol:
>>res = eqns.sweep(dt=1e-15)
>>print(res)
>> 
>> Best,
>> Yuranan
>> 
>> 
>> ___
>> 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 ]


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

Re: Charge dynamics and Neumann boundary conditions

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Yuranan -

There are a few things going on here.

I've modified your notebook and posted it at 
https://github.com/guyer/sharing-github/blob/master/ion-transport-diagnosis.ipynb.

The singular matrix has gone away, but the solution diverges. In general, I 
find the drift-diffusion equations pretty challenging to solve. Newton-Raphson 
iterations are almost always called for and under-relaxation or other damping 
can be needed, too.

- Jon

> On Feb 24, 2020, at 7:11 PM, Yuranan Hanlumyuang  wrote:
> 
> Dear the FiPy Team,
> 
> We are trying to solve the coupled equations in the paper titled 
> "Diffuse-charge dynamics in electrochemical systems" by Bazant, Thornton and 
> Ajdari using FiPy.  I am posting a copy of the python code and the equations 
> here https://bit.ly/32fIA8a
> 
> The example of Binary_Electrolytes posted by Prof. Guyer has been followed 
> closely. However, we keep encountering the errors of self.factorizeFnc(*args, 
> **kwargs) with the RuntimeError: Factor is exactly singular. We were unable 
> to diagnose if there is anything wrong with the way we set (1) the boundary 
> conditions, or (2) the coupled equations. 
> 
> We tried to use “eqns.solve()” as well, but still it didn’t work.  I would 
> appreciate any guidance that you can offer.   
> 
> The code in the text format is listed below: 
> from fipy import *
> 
> m = Grid1D(nx=100,Lx=2.0)
> 
> v = 1
> epsilon= 0.05
> delta = 0.1
> x = m.cellCenters[0]
> 
> 
> ##Initial conditions
> c = CellVariable(name="c", mesh=m , value=1.0, hasOld=True)
> 
> rho = CellVariable(name="rho", mesh=m , value=0.0, hasOld=True)
> 
> phi = CellVariable(name="phi",mesh=m, hasOld=True)
> phi.setValue(v*(x-1), where=m.cellCenters)
> 
> #vi =Viewer((phi, c, rho),datamin=-1.1, datamax=1.1)
> #vi.plot()
> 
> 
> ##Boundary conditions
> c.faceGrad.constrain(-rho.faceValue*phi.faceGrad, where=m.facesLeft)
> c.faceGrad.constrain(-rho.faceValue*phi.faceGrad, where=m.facesRight)
> 
> rho.faceGrad.constrain(-c.faceValue*phi.faceGrad, where=m.facesLeft)
> rho.faceGrad.constrain(-c.faceValue*phi.faceGrad, where=m.facesRight)
> 
> 
> phi.faceGrad.constrain((phi.faceValue+v)/(epsilon*delta), where=m.facesLeft)
> phi.faceGrad.constrain((phi.faceValue-v)/(-epsilon*delta), where=m.facesRight)
> 
> 
> ##Equations
> 
> Drho = epsilon*rho
> Dc   = epsilon*c
> 
> eq1 = TransientTerm(var=c) == DiffusionTerm(coeff=epsilon, var=c) 
> +DiffusionTerm(coeff=Drho, var=phi)
> eq2 = TransientTerm(var=rho) == DiffusionTerm(coeff=epsilon, var=rho) 
> +DiffusionTerm(coeff=Dc, var=phi)
> eq3 = DiffusionTerm(coeff=epsilon*epsilon, 
> var=phi)+ImplicitSourceTerm(coeff=1.0, var=rho) == 0
> eqns = eq1 & eq2 & eq3 
> 
> 
> ##Solve
> #vi =Viewer((phi, c, rho),datamin=-1.1, datamax=1.1)
> #from builtins import range
> 
> res = 1e+10
> restol= 1e-13
> 
> for t in range(100):
> c.updateOld()
> rho.updateOld()
> phi.updateOld()
> while res > restol:
> res = eqns.sweep(dt=1e-15)
> print(res)
> 
> Best,
> Yuranan
> 
> 
> ___
> 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: More on VTK objects and mesh plotting with 3rd party packaages

[Guyer, Jonathan E. Dr. (Fed) via fipy]

> On Feb 23, 2020, at 8:43 AM, A A  wrote:
> 
> Uncommenting line 7 of the above code reveals that resetting the cell type 
> from 41 to 7 of the UniformGrid2D's underlying tvtk object allows the mesh to 
> appear in the plotter. 
> 
> I recall from previous discussions that failure of cell type 41 to plot was 
> attributed to incorrect ordering of the cell vertices, but this would be in 
> contradiction with the results of the code above.


>From the [VTK 
>documentation](https://vtk.org/doc/release/4.2/html/classvtkConvexPointSet.html),
> "vtkConvexPointSet is a concrete implementation that represents a 3D cell 
>defined by a convex set of points." FiPy does not output vertices correctly 
>for this 3D object. The fact that a Grid2D outputs its vertices in the correct 
>order for a VTK_POLYGON does not change the fact that the ordering is wrong 
>for VTK_CONVEX_POINT_SET.

The docstring for UniformGrid2D._calcOrderedCellVertexIDs says "Correct 
ordering for VTK_PIXEL", but it does not do this. It produces the ordering for 
VTK_QUAD (which also works for VTK_POLYGON).

The docstring for UniformGrid3D._calcOrderedCellVertexIDs correctly states 
"Correct ordering for `VTK_VOXEL`".

The proper interim fix is to make the following changes:

diff --git a/fipy/meshes/nonUniformGrid3D.py b/fipy/meshes/nonUniformGrid3D.py
index 8e78c5319..03097e2b7 100644
--- a/fipy/meshes/nonUniformGrid3D.py
+++ b/fipy/meshes/nonUniformGrid3D.py
@@ -116,6 +116,14 @@ class NonUniformGrid3D(Mesh):
 faceTangents2[2, self.numberOfXYFaces + self.numberOfXZFaces:] = 1.
 return faceTangents1, faceTangents2
 
+@property
+def _VTKCellType(self):
+try:
+from tvtk.api import tvtk
+except ImportError as e:
+from enthought.tvtk.api import tvtk
+return tvtk.Voxel().cell_type
+
 ## The following method is broken when dx, dy or dz are not scalar. Simpler to 
use the generic
 ## _calcFaceAreas rather than do the required type checking, resizing and 
outer product.
 ##
diff --git a/fipy/meshes/uniformGrid1D.py b/fipy/meshes/uniformGrid1D.py
index 041f8ed9d..931f3f708 100644
--- a/fipy/meshes/uniformGrid1D.py
+++ b/fipy/meshes/uniformGrid1D.py
@@ -288,6 +288,14 @@ class UniformGrid1D(UniformGrid):
 c1 = numerix.arange(self.numberOfCells)
 return numerix.array((c1 + 1, c1))
 
+@property
+def _VTKCellType(self):
+try:
+from tvtk.api import tvtk
+except ImportError as e:
+from enthought.tvtk.api import tvtk
+return tvtk.Line().cell_type
+
 def _getNearestCellID(self, points):
 """
 Test cases
diff --git a/fipy/meshes/uniformGrid2D.py b/fipy/meshes/uniformGrid2D.py
index 16815c689..37d3ebfa6 100644
--- a/fipy/meshes/uniformGrid2D.py
+++ b/fipy/meshes/uniformGrid2D.py
@@ -560,6 +560,14 @@ class UniformGrid2D(UniformGrid):
 
 return ids.reshape((4, self.numberOfCells), order='F')
 
+@property
+def _VTKCellType(self):
+try:
+from tvtk.api import tvtk
+except ImportError as e:
+from enthought.tvtk.api import tvtk
+return tvtk.Quad().cell_type
+
 def _getNearestCellID(self, points):
 """
 Test cases
diff --git a/fipy/meshes/uniformGrid3D.py b/fipy/meshes/uniformGrid3D.py
index 4ad7a3b69..29990f53e 100644
--- a/fipy/meshes/uniformGrid3D.py
+++ b/fipy/meshes/uniformGrid3D.py
@@ -491,6 +491,14 @@ class UniformGrid3D(UniformGrid):
 
 return numerix.reshape(ids.swapaxes(1, 3), (8, self.numberOfCells))
 
+@property
+def _VTKCellType(self):
+try:
+from tvtk.api import tvtk
+except ImportError as e:
+from enthought.tvtk.api import tvtk
+return tvtk.Voxel().cell_type
+
 ## scaling
 
 def _getNearestCellID(self, points):


This will fix the Grid classes. It definitely doesn't fix arbitrary 3D meshes.
___
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]

Re: More on VTK objects and mesh plotting with 3rd party packaages

[Guyer, Jonathan E. Dr. (Fed) via fipy]

AbstractMesh is abstract. It makes no assumptions about geometry, topology, or 
dimensionality. Forcing it to render as VTK_POLYGON, an intrinsically 2D 
object, is not appropriate.

> On Feb 23, 2020, at 8:43 AM, A A  wrote:
> 
> Dear All,
> 
> This question is loosely related to 
> https://github.com/usnistgov/fipy/issues/312 but might perhaps not be exactly 
> the same. I ran some tests in which I tried to plot a "broken" mesh by 
> resetting the cell type of the underlying tvtk object the same way fipy's 
> VTKCellDataSet method does:
> 
> from fipy import Grid2D
> import pyvista
> 
> # Create Mesh
> mesh = Grid2D(dx = 1.0, dy = 1.0, nx = 2, ny = 2)
> ug = mesh.VTKCellDataSet
> #ug.set_cells([7,7,7,7], ug.cell_locations_array.to_array(), ug.get_cells()) 
> # overwrite to
> ugrid= pyvista.UnstructuredGrid(ug._vtk_obj)
> 
> # Plot Mesh
> plotter = pyvista.Plotter()
> plotter.set_background('white')
> plotter.add_mesh(ugrid, style='wireframe', color='black')
> plotter.add_bounding_box(color='red')
> 
> plotter.view_xy()
> plotter.show()
> 
> Uncommenting line 7 of the above code reveals that resetting the cell type 
> from 41 to 7 of the UniformGrid2D's underlying tvtk object allows the mesh to 
> appear in the plotter. 
> 
> I recall from previous discussions that failure of cell type 41 to plot was 
> attributed to incorrect ordering of the cell vertices, but this would be in 
> contradiction with the results of the code above.
> 
> I then looked through fipy's source code and came up with the following 
> inheritance diagram:
> 
> 
> The _VTKCellType method in AbstractMesh returns 
> tvtk.ConvexPointSet().cell_type while the  _VTKCellType method in Mesh2D 
> returns tvtk.Polygon().cell_type. I am quite sure that forcing AbstractMesh 
> to return  tvtk.Polygon().cell_type would cause the UniformGrid2D object to 
> appear in pyvista/mayavi, though I am not sure whether this is a viable 
> solution. Any thoughts?
> 
> Regards,
> 
> Amine
> 
> ___
> 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: ANN: FiPy 3.4

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Thanks for the kind words, Martin.

I think Pysparse on Py3k is unlikely. That project has been dormant for many 
years. While Daniel does have commit rights to the code, modernizing that 
codebase is really not something we have the time or expertise for.

My hope is that we will be able to improve the performance of PETSc. I have 
some ideas on this and just need to find the time to do some troubleshooting. 
Finishing the integration of PETSc and getting the conda feedstocks we depend 
on working took a *long* time and I've got a lot of other things I need to 
catch up on. This is a priority, though, as we hadn't realized how bad the 
situation was. I thought the cross-over was at 2-4 cpus, not 10-30!

- Jon

> On Feb 6, 2020, at 11:37 AM, Martinus WERTS  
> wrote:
> 
> Dear Fipy developers,
> 
> Many thanks for Fipy, and congratulations on the new version.
> 
> I do not have the occasion to work with Fipy as often as I would like, but 
> last Thursday, two students started a small numerical research project with 
> Fipy. The new Fipy release happened just before, which I consider to be some 
> kind of sign of good fortune. 
> 
> I have had students working with Fipy before, but for the first time, these 
> students had been able to install Fipy just by installing Anaconda and 
> clicking somewhere in the supplied "Navigator", instead of following some 
> obscure build recipe concocted by me. They now have 3.4 on their computers 
> and have started running some simple (cylindrical grid) diffusion/advection 
> problems. I know (through painful experiences) that conda is far from 
> perfect, but it did the job this time.
> 
> Many thanks again for Fipy (and any future work that you might do, in 
> particular on fixing issues with cylindrical grids and implementation of 1D 
> spherical grid... simple geometries are very good for getting started with 
> Fipy, and also helpful for building simple models)
> 
> Best wishes,
> 
> Martin
> 
> 
> P.S. I inadvertedly did a small benchmark with Fipy 3.4 on my own Linux 
> laptop computer (I ran an old script that I used to run on Fipy 3.1.x, Python 
> 2.7, pysparse)... now I understand what "lagging by a considerable margin" 
> means when you talk about the different solvers (scipy, but also 
> single-thread PetSc)! Wouldn't it be nice if Pysparse worked with Py3k? 
> Meanwhile, I'll keep a Python 2.7+pysparse environment around somewhere in 
> the lab... 
> 
> 
> 
> 
> 
> 
> On 29/01/2020 15:01, Guyer, Jonathan E. Dr. (Fed) via fipy wrote:
>> Some notes about this release:
>> 
>> - Because conda is a dreary pain in the behind, it appears to be necessary 
>> to specify
>>   `conda install --channel conda-forge fipy=3.4`
>>   otherwise fipy 3.3 takes precedence for some reason.
>> - PETSc supports Py3k in parallel (as well as Python 2.7). 
>> - PyTrilinos is available from conda-forge for Python 2.7. 
>>   In principle, it works with Py3k as well, but we won't be 
>>   attempting to build it to find out.
>> - On Python 2.7, PETSc and PyTrilinos have comparable performance.
>>   Unfortunately, this performance lags serial PySparse by a 
>>   considerable margin. Serial SciPy lags them all.
>>   See 
>> https://www.ctcms.nist.gov/fipy/documentation/USAGE.html#solving-in-parallel
>> 
>>   for discussion. 
>>   Until we can sort this out, we won't be (willingly) dropping support for 
>> Python 2.
>> 
>> 
>>> On Jan 29, 2020, at 8:51 AM, Guyer, Jonathan E. Dr. (Fed) via fipy 
>>> 
>>>  wrote:
>>> 
>>> We are pleased to announce the release of FiPy 3.4.
>>> 
>>> 
>>> http://www.ctcms.nist.gov/fipy
>>> 
>>> 
>>> This release adds support for the PETSc solvers for solving in parallel.
>>> 
>>> Pulls
>>> -
>>> 
>>> - Add support for PETSc solvers (#701)
>>> - Assorted fixes while supporting PETSc (#700)
>>>  - Fix print statements for Py3k
>>>  - Resolve Gmsh issues
>>>  - Dump only on processor 0
>>>  - Only write `timetests` on processor 0
>>>  - Fix conda-forge link
>>>  - Upload PDF
>>>  - Document `print` option of `FIPY_DISPLAY_MATRIX`
>>>  - Use legacy numpy formatting when testing individual modules
>>>  - Switch to matplotlib's built-in symlog scaling
>>>  - Clean up tests
>>> - Assorted fixes for benchmark 8 (#699)
>>>  - Stipulate `--force` option for `conda remove fipy`
>>>  - Update Miniconda installation url
>>>  - Replace `_CellVolumeAverageVariable` class with `Variable` expression
>>>  - Fix output

Re: ANN: FiPy 3.4

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Some notes about this release:

- Because conda is a dreary pain in the behind, it appears to be necessary to 
specify
  `conda install --channel conda-forge fipy=3.4`
  otherwise fipy 3.3 takes precedence for some reason.
- PETSc supports Py3k in parallel (as well as Python 2.7). 
- PyTrilinos is available from conda-forge for Python 2.7. 
  In principle, it works with Py3k as well, but we won't be 
  attempting to build it to find out.
- On Python 2.7, PETSc and PyTrilinos have comparable performance.
  Unfortunately, this performance lags serial PySparse by a 
  considerable margin. Serial SciPy lags them all.
  See 
https://www.ctcms.nist.gov/fipy/documentation/USAGE.html#solving-in-parallel
  for discussion. 
  Until we can sort this out, we won't be (willingly) dropping support for 
Python 2.

> On Jan 29, 2020, at 8:51 AM, Guyer, Jonathan E. Dr. (Fed) via fipy 
>  wrote:
> 
> We are pleased to announce the release of FiPy 3.4.
> 
> http://www.ctcms.nist.gov/fipy
> 
> This release adds support for the PETSc solvers for solving in parallel.
> 
> Pulls
> -
> 
> - Add support for PETSc solvers (#701)
> - Assorted fixes while supporting PETSc (#700)
>  - Fix print statements for Py3k
>  - Resolve Gmsh issues
>  - Dump only on processor 0
>  - Only write `timetests` on processor 0
>  - Fix conda-forge link
>  - Upload PDF
>  - Document `print` option of `FIPY_DISPLAY_MATRIX`
>  - Use legacy numpy formatting when testing individual modules
>  - Switch to matplotlib's built-in symlog scaling
>  - Clean up tests
> - Assorted fixes for benchmark 8 (#699)
>  - Stipulate `--force` option for `conda remove fipy`
>  - Update Miniconda installation url
>  - Replace `_CellVolumeAverageVariable` class with `Variable` expression
>  - Fix output for bad call stack
> - Make CircleCI build docs on Py3k (#698)
> - Fix link to Nick Croft's thesis (#681)
> - Fix NIST header footer (#680)
> - Use Nixpkgs version of FiPy expression (#661)
> - Update the Nix recipe (#658)
> 
> Fixes
> -
> 
> - #692: Can't copy example scripts with the command line
> - #669: input() deadlock on parallel runs
> - #643: Automate release process
> 
> 
> 
> 
> FiPy is an object oriented, partial differential equation (PDE) solver,
> written in Python, based on a standard finite volume (FV) approach. The
> framework has been developed in the Metallurgy Division and Center for
> Theoretical and Computational Materials Science (CTCMS), in the Material
> Measurement Laboratory (MML) at the National Institute of Standards and
> Technology (NIST).
> 
> The solution of coupled sets of PDEs is ubiquitous to the numerical
> simulation of science problems. Numerous PDE solvers exist, using a variety
> of languages and numerical approaches. Many are proprietary, expensive and
> difficult to customize. As a result, scientists spend considerable
> resources repeatedly developing limited tools for specific problems. Our
> approach, combining the FV method and Python, provides a tool that is
> extensible, powerful and freely available. A significant advantage to
> Python is the existing suite of tools for array calculations, sparse
> matrices and data rendering.
> 
> The FiPy framework includes terms for transient diffusion, convection and
> standard sources, enabling the solution of arbitrary combinations of
> coupled elliptic, hyperbolic and parabolic PDEs. Currently implemented
> models include phase field treatments of polycrystalline, dendritic, and
> electrochemical phase transformations as well as a level set treatment of
> the electrodeposition process.
> 
> 
> ___
> 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 ]


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

ANN: FiPy 3.4

[Guyer, Jonathan E. Dr. (Fed) via fipy]

We are pleased to announce the release of FiPy 3.4.

http://www.ctcms.nist.gov/fipy

This release adds support for the PETSc solvers for solving in parallel.

Pulls
-

- Add support for PETSc solvers (#701)
- Assorted fixes while supporting PETSc (#700)
  - Fix print statements for Py3k
  - Resolve Gmsh issues
  - Dump only on processor 0
  - Only write `timetests` on processor 0
  - Fix conda-forge link
  - Upload PDF
  - Document `print` option of `FIPY_DISPLAY_MATRIX`
  - Use legacy numpy formatting when testing individual modules
  - Switch to matplotlib's built-in symlog scaling
  - Clean up tests
- Assorted fixes for benchmark 8 (#699)
  - Stipulate `--force` option for `conda remove fipy`
  - Update Miniconda installation url
  - Replace `_CellVolumeAverageVariable` class with `Variable` expression
  - Fix output for bad call stack
- Make CircleCI build docs on Py3k (#698)
- Fix link to Nick Croft's thesis (#681)
- Fix NIST header footer (#680)
- Use Nixpkgs version of FiPy expression (#661)
- Update the Nix recipe (#658)

Fixes
-

- #692: Can't copy example scripts with the command line
- #669: input() deadlock on parallel runs
- #643: Automate release process




FiPy is an object oriented, partial differential equation (PDE) solver,
written in Python, based on a standard finite volume (FV) approach. The
framework has been developed in the Metallurgy Division and Center for
Theoretical and Computational Materials Science (CTCMS), in the Material
Measurement Laboratory (MML) at the National Institute of Standards and
Technology (NIST).

The solution of coupled sets of PDEs is ubiquitous to the numerical
simulation of science problems. Numerous PDE solvers exist, using a variety
of languages and numerical approaches. Many are proprietary, expensive and
difficult to customize. As a result, scientists spend considerable
resources repeatedly developing limited tools for specific problems. Our
approach, combining the FV method and Python, provides a tool that is
extensible, powerful and freely available. A significant advantage to
Python is the existing suite of tools for array calculations, sparse
matrices and data rendering.

The FiPy framework includes terms for transient diffusion, convection and
standard sources, enabling the solution of arbitrary combinations of
coupled elliptic, hyperbolic and parabolic PDEs. Currently implemented
models include phase field treatments of polycrystalline, dendritic, and
electrochemical phase transformations as well as a level set treatment of
the electrodeposition process.


___
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: Some questions on the viewer

[Guyer, Jonathan E. Dr. (Fed) via fipy]

I'm not sure why you are skeptical. FiPy does not use VTK internally, so the 
fact that the FiPy mesh is defined appropriately for its own use has nothing to 
do with whether we export it correctly as VTK. It would appear that we do not 
output VTK_CONVEX_POINT_SETs correctly.


From: A A 
Sent: Thursday, January 23, 2020 6:10 AM
To: Guyer, Jonathan E. Dr. (Fed); FIPY
Subject: Re: Some questions on the viewer

Hi Jon,

It looks like pyvista does support VTK_CONVEX_POINT_SET. Please take a look at 
the discussion I started on 
https://github.com/pyvista/pyvista-support/issues/108

They are claiming that fipy's mesh might be ill-formed which I am a bit 
skeptical about. For instance I think Grid2D works fine, but for some reason I 
still get a blank plot with pyvista.

A contribution from the fipy team on the above discussion would be most useful. 
If there is a resolution I'd be happy to take a look at submitting a pull 
request for a pyvista-enabled Viewer class, though I may need some guidance in 
order not to break things.

Regards,

Amine


On Wed, Jan 22, 2020 at 6:19 PM Guyer, Jonathan E. Dr. (Fed) via fipy 
mailto:fipy@nist.gov>> wrote:
FiPy can have completely general polyhedral cells, whereas VTK is more 
restrictive. In principle, VTK_CONVEX_POINT_SET allows the same generality, but 
as you've seen, this cell type is not implemented by many tools using VTK.

General 2D meshes know to export VTK_POLYGONs, which are widely understood.

2D grids bypass this specialization for historical reasons and so just get the 
default VTK_CONVEX_POINT_SET. We've never had any call to render 2D grids with 
VTK tools, so we've not noticed this before. Grid meshes should be exported as 
VTK_PIXEL or VTK_VOXEL. Fixing in this in FiPy is likely to happen sooner than 
getting any of those other packages to support VTK_CONVEX_POINT_SET. I have a 
(stalled) development that does a better job with mesh io, but higher priority 
tasks have gotten in the way.

> On Jan 22, 2020, at 10:11 AM, A A 
> mailto:amine.aboufir...@gmail.com>> wrote:
>
>
> This is somewhat related to my last comment about visualizing meshes. I'm 
> noticing that both CylindricalGrid2D and Grid2D default to a cell type of 41 
> which according to VTK is a VTK_CONVEX_POINT_SET (see  
> https://vtk.org/doc/nightly/html/vtkCellType_8h_source.html<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvtk.org%2Fdoc%2Fnightly%2Fhtml%2FvtkCellType_8h_source.html=02%7C01%7Cjonathan.guyer%40nist.gov%7C5610ae87d73b44e97ca208d79ff4dec5%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637153746369115046=%2BAIrNqP67P9zTUr7UfO%2BKj6Avo6gHUQ4q0GfizRHb50%3D=0>).
>  Interestingly, the mesh generated in fipy's circle diffusion example  using 
> gmesh capability results in a mesh of cell type 7 which is a VTK_POLYGON. I'm 
> suspecting that the third party libraries I'm using to plot these meshes 
> might be limited to cell types with numbers ranging from 0 to 35 thus not 
> including fipy's choice of cell type 41.
>
> Is the choice of the cell type intentional or important here? If so it might 
> be worth convincing those libraries to add cell type 41 plotting and i/o 
> capabilities.
> -- Forwarded message -
> From: A A mailto:amine.aboufir...@gmail.com>>
> Date: Wed, Jan 22, 2020 at 12:22 PM
> Subject: Re: Some questions on the viewer
> To: Guyer, Jonathan E. Dr. (Fed) 
> mailto:jonathan.gu...@nist.gov>>, 
> mailto:fipy@nist.gov>>
>
>
> Hi Jonathan,
>
> The lines do remain dashed on successive calls. I guess the viewer keeps 
> pointing to the right objects even if their properties are retroactively 
> modified.
>
> Here's what I mean about the diffusion term:
>
> 
>
> On another note, I've posted some stuff on github which may be of interest 
> regarding the circle diffusion example. I had a hard time visualizing the 
> mesh so I went with some third-party packages (pyvista, pygmsh) and the 
> result looks quite nice. https://github.com/usnistgov/fipy/issues/693
>
> I'm now experimenting with cylindrical coordinates as I would like to try to 
> solve the heat equation in radial terms. I tried repeating the above 
> procedure to visualize CylindricalGrid1D and CylindricalGrid2D  objects but 
> without much luck. Here's what I'm doing:
>
> from fipy import Variable, FaceVariable, CellVariable, Grid1D, 
> CylindricalGrid1D, CylindricalGrid2D, ExplicitDiffusionTerm, TransientTerm, 
> DiffusionTerm, Viewer
> from fipy.tools import numerix
> import numpy as np
> import pyvista
>
> mesh = CylindricalGrid2D(dr=0.1, dz=0.25, nr=3, nz=0.1)
> ugrid= pyvista.UnstructuredGrid(mesh.VTKCellDataSet._vtk_obj)
> plotter = pyvista.Plotter()
> plotter.set_background('white')
> plotter.add_mesh(ugrid

viewing cylindrical grids [was Re: Some questions on the viewer]

[Guyer, Jonathan E. Dr. (Fed) via fipy]

I've added comments to your https://github.com/usnistgov/fipy/issues/693, but 
the short answer is that FiPy's not exporting a VTK cell type that pyvista 
understands. FiPy should put out VTK_PIXELs or VTK_QUADs in this case.

> On Jan 22, 2020, at 6:22 AM, A A  wrote:
> 
> On another note, I've posted some stuff on github which may be of interest 
> regarding the circle diffusion example. I had a hard time visualizing the 
> mesh so I went with some third-party packages (pyvista, pygmsh) and the 
> result looks quite nice. https://github.com/usnistgov/fipy/issues/693
> 
> I'm now experimenting with cylindrical coordinates as I would like to try to 
> solve the heat equation in radial terms. I tried repeating the above 
> procedure to visualize CylindricalGrid1D and CylindricalGrid2D  objects but 
> without much luck. Here's what I'm doing:
> 
> from fipy import Variable, FaceVariable, CellVariable, Grid1D, 
> CylindricalGrid1D, CylindricalGrid2D, ExplicitDiffusionTerm, TransientTerm, 
> DiffusionTerm, Viewer
> from fipy.tools import numerix
> import numpy as np
> import pyvista
> 
> mesh = CylindricalGrid2D(dr=0.1, dz=0.25, nr=3, nz=0.1)
> ugrid= pyvista.UnstructuredGrid(mesh.VTKCellDataSet._vtk_obj)
> plotter = pyvista.Plotter()
> plotter.set_background('white')
> plotter.add_mesh(ugrid, style='wireframe', color='black')
> plotter.add_bounding_box(color='red')
> plotter.show_grid(color="red")
> plotter.view_xy()
> plotter.show()
> 
> I only get the red bounding box/grid but no cylindrical mesh. Is there 
> something I'm missing regarding the nature of CylindricalGrid objects? It 
> seems that fipy is working with/using VTK under the hood so it would be nice 
> to be able to recover it and take a look at what I'm working with...


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

nth-order diffusion [was Re: Some questions on the viewer]

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Amine -

The n is effectively a power, or how many times the operator 
$\nabla\cdot\Gamma\nabla$ should be applied. The index i runs from 1..n to 
denote that each operator gets its own coefficient. 

If n=1, then apply the operator $\nabla\cdot\Gamma_1\nabla$ to the argument 
$\phi$ and you get the "normal" 2nd-order diffusion. 

If n=2, then apply the operator $\nabla\cdot\Gamma_1\nabla$ to the argument 
consisting of the operator ($\nabla\cdot\Gamma_2\nabla$ applied to the argument 
$\phi$) and you get a 4th-order expression that comes up in Cahn-Hilliard 
problems. 

If n=3, then apply the operator $\nabla\cdot\Gamma_1\nabla$ to the argument 
consisting of the operator ($\nabla\cdot\Gamma_2\nabla$ applied to the argument 
($\nabla\cdot\Gamma_3\nabla$ applied to the argument $\phi$)) and you get a 
6th-order expression that comes up in phase field crystal.

Repeat as necessary.

If you don't have terms like this in your equations, don't worry about it. Even 
if you do, you're probably better off doing operator splitting, e.g., instead of

\nabla\cdot(\Gamma_1\nabla[\nabla\cdot\Gamma_2\nabla\phi])

do 

\nabla\cdot(\Gamma_1\nabla\psi)

and

\psi = \nabla\cdot\Gamma_2\nabla\phi

- Jon

> On Jan 22, 2020, at 6:22 AM, A A  wrote:
> 
> Here's what I mean about the diffusion term:
> 
> 
> 


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

Re: Some questions on the viewer

[Guyer, Jonathan E. Dr. (Fed) via fipy]

FiPy can have completely general polyhedral cells, whereas VTK is more 
restrictive. In principle, VTK_CONVEX_POINT_SET allows the same generality, but 
as you've seen, this cell type is not implemented by many tools using VTK.

General 2D meshes know to export VTK_POLYGONs, which are widely understood.

2D grids bypass this specialization for historical reasons and so just get the 
default VTK_CONVEX_POINT_SET. We've never had any call to render 2D grids with 
VTK tools, so we've not noticed this before. Grid meshes should be exported as 
VTK_PIXEL or VTK_VOXEL. Fixing in this in FiPy is likely to happen sooner than 
getting any of those other packages to support VTK_CONVEX_POINT_SET. I have a 
(stalled) development that does a better job with mesh io, but higher priority 
tasks have gotten in the way.

> On Jan 22, 2020, at 10:11 AM, A A  wrote:
> 
> 
> This is somewhat related to my last comment about visualizing meshes. I'm 
> noticing that both CylindricalGrid2D and Grid2D default to a cell type of 41 
> which according to VTK is a VTK_CONVEX_POINT_SET (see  
> https://vtk.org/doc/nightly/html/vtkCellType_8h_source.html). Interestingly, 
> the mesh generated in fipy's circle diffusion example  using gmesh capability 
> results in a mesh of cell type 7 which is a VTK_POLYGON. I'm suspecting that 
> the third party libraries I'm using to plot these meshes might be limited to 
> cell types with numbers ranging from 0 to 35 thus not including fipy's choice 
> of cell type 41.
> 
> Is the choice of the cell type intentional or important here? If so it might 
> be worth convincing those libraries to add cell type 41 plotting and i/o 
> capabilities.
> -- Forwarded message -
> From: A A 
> Date: Wed, Jan 22, 2020 at 12:22 PM
> Subject: Re: Some questions on the viewer
> To: Guyer, Jonathan E. Dr. (Fed) , 
> 
> 
> Hi Jonathan,
> 
> The lines do remain dashed on successive calls. I guess the viewer keeps 
> pointing to the right objects even if their properties are retroactively 
> modified.
> 
> Here's what I mean about the diffusion term:
> 
> 
> 
> On another note, I've posted some stuff on github which may be of interest 
> regarding the circle diffusion example. I had a hard time visualizing the 
> mesh so I went with some third-party packages (pyvista, pygmsh) and the 
> result looks quite nice. https://github.com/usnistgov/fipy/issues/693
> 
> I'm now experimenting with cylindrical coordinates as I would like to try to 
> solve the heat equation in radial terms. I tried repeating the above 
> procedure to visualize CylindricalGrid1D and CylindricalGrid2D  objects but 
> without much luck. Here's what I'm doing:
> 
> from fipy import Variable, FaceVariable, CellVariable, Grid1D, 
> CylindricalGrid1D, CylindricalGrid2D, ExplicitDiffusionTerm, TransientTerm, 
> DiffusionTerm, Viewer
> from fipy.tools import numerix
> import numpy as np
> import pyvista
> 
> mesh = CylindricalGrid2D(dr=0.1, dz=0.25, nr=3, nz=0.1)
> ugrid= pyvista.UnstructuredGrid(mesh.VTKCellDataSet._vtk_obj)
> plotter = pyvista.Plotter()
> plotter.set_background('white')
> plotter.add_mesh(ugrid, style='wireframe', color='black')
> plotter.add_bounding_box(color='red')
> plotter.show_grid(color="red")
> plotter.view_xy()
> plotter.show()
> 
> I only get the red bounding box/grid but no cylindrical mesh. Is there 
> something I'm missing regarding the nature of CylindricalGrid objects? It 
> seems that fipy is working with/using VTK under the hood so it would be nice 
> to be able to recover it and take a look at what I'm working with...
> 
> Regards,
> 
> Amine
> 
> On Tue, Jan 21, 2020 at 3:55 PM Guyer, Jonathan E. Dr. (Fed) via fipy 
>  wrote:
> I'm curious. Do the lines remain dashed on successive calls to plot()?
> 
> As to the third question, where are you seeing exponent n and subscript i? 
> I'm not suggesting we don't use them, just that I don't know where.
> 
> Is the discussion at
> https://www.ctcms.nist.gov/fipy/documentation/numerical/discret.html#higher-order-diffusion
> helpful?
> 
> > On Jan 21, 2020, at 1:25 AM, A A  wrote:
> > 
> > Hi Martin,
> > 
> > Thanks for your response. That's strange that such a "dummy" command would 
> > be necessary. 
> > 
> > I was able to answer the second question myself. It is possible to 
> > retroactively change line and axis properties. For the mesh1D example I did 
> > the following:
> > 
> > viewer = Viewer(vars=(phi, phi_analytical), datamin=-6.0, datamax=6.0)
> > ax = viewer.axes
> > ax.lines[-1].set_dashes((3.5,3.5,3.5,3.5))
> > ax.grid()
> > viewer.plot()
> > 
> > Which seemed to work quite well. 
> 

Re: Some questions on the viewer

[Guyer, Jonathan E. Dr. (Fed) via fipy]

I'm curious. Do the lines remain dashed on successive calls to plot()?

As to the third question, where are you seeing exponent n and subscript i? I'm 
not suggesting we don't use them, just that I don't know where.

Is the discussion at
https://www.ctcms.nist.gov/fipy/documentation/numerical/discret.html#higher-order-diffusion
helpful?

> On Jan 21, 2020, at 1:25 AM, A A  wrote:
> 
> Hi Martin,
> 
> Thanks for your response. That's strange that such a "dummy" command would be 
> necessary. 
> 
> I was able to answer the second question myself. It is possible to 
> retroactively change line and axis properties. For the mesh1D example I did 
> the following:
> 
> viewer = Viewer(vars=(phi, phi_analytical), datamin=-6.0, datamax=6.0)
> ax = viewer.axes
> ax.lines[-1].set_dashes((3.5,3.5,3.5,3.5))
> ax.grid()
> viewer.plot()
> 
> Which seemed to work quite well. 
> 
> With regards to the third question, I think the terms in the general 
> conservation equation are explained reasonably well in the fipy docs, except 
> for the diffusion term. It is unclear what the exponent n and subscript i 
> represent and how they are related to one another. Is the exponent an 
> arithmetic exponent? Is i part of a sum? I had trouble expanding the 
> diffusion term to n>=4.
> 
> Regards,
> 
> Amine
> 
> On Mon, Jan 20, 2020 at 5:23 PM Martinus WERTS  
> wrote:
> Dear Amine,
> 
> Concerning your second question, I think that this a normal (but in this 
> case, annoying) feature of the Jupyter notebook. 
> 
> You might trying adding an extra (dummy) command to the cell, after the line 
> in which the Viewer() is instantiated. For example: ``print('Ready')``.
> 
> Best,
> Martin
> 
> On 20/01/2020 17:01, A A wrote:
>> Dear All,
>> 
>> I'm just getting back into using fipy after a few months hiatus. I'm getting 
>> more familiar with how it works, but I have a couple of questions about the 
>> viewer:
>>  • Is it possible to control linestyle (specifically dashes)  of the 
>> cellVariable objects tied to each specific viewer? I'd like to avoid the 
>> possibility of superimposing very similar plots and thinking they are the 
>> same
>>  • I am primarily using jupyter notebook to practice some basic 
>> concepts. What I've found is that simply instantiating the viewer in 
>> interactive mode will generate a plot. This renders a viewer.plot() call 
>> redundant. When I run the whole notebook in non-interactive mode I get the 
>> expected behavior, namely one plot with a .plot() call. Am I missing 
>> something here? Why does viewer instantiation generate a plot in jupyter 
>> notebook?
>> Thanks for your help and look forward to your reply.
>> 
>> Regards,
>> 
>> Amine Aboufirass
>> 
>> 
>> ___
>> 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 ]
> ___
> 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: Problem in dump.write for vector variables

[Guyer, Jonathan E. Dr. (Fed) via fipy]

I filed https://github.com/usnistgov/fipy/issues/691 to address this

> On Jan 9, 2020, at 8:34 AM, Guyer, Jonathan E. Dr. (Fed) via fipy 
>  wrote:
> 
> Thank you for the feedback. I'm inclined to agree.
> 
> - Jon
> 
>> On Jan 9, 2020, at 3:47 AM, Marcel UJI (IMAP)  wrote:
>> 
>> Hi Jonathan
>> 
>> Sorry by my late reply
>> 
>> I think that the second one would be enough as I only need to read this data 
>> later for further processing. Actually this is not much an issue, as I can 
>> simply save phi and later recompute phi.faceGrad, which is also much more 
>> economic in terms of storage.
>> 
>> Thank you anyway for spending some time on this
>> 
>> Marcel
>> 
>> 
>> 
>> El 20/12/19 a les 16:27, Guyer, Jonathan E. Dr. (Fed) via fipy ha escrit:
>>> Glad you found a solution, Marcel.
>>> 
>>> The issue is that a FaceGradVariable doesn't pickle itself properly. It 
>>> stores the state for a generic FaceVariable, but then it doesn't know how 
>>> to rebuild itself from that.
>>> 
>>> It either should 
>>> - pickle the correct information, which would also involve pickling phi
>>> OR
>>> - pickle itself as a plain FaceVariable, losing connection to phi on 
>>> unpickling (which is what your solution does)
>>> 
>>> Do you have an opinion on which behavior you'd like?
>>> 
>>> 
>>>> On Dec 20, 2019, at 2:35 AM, Marcel UJI (IMAP) 
>>>> wrote:
>>>> 
>>>> Thank you Trevor,
>>>> 
>>>> This works, but it saves the array values only. 
>>>> 
>>>> I found an alternative solution with:
>>>> 
>>>> dump.write({'E' : 
>>>> FaceVariable(mesh=mesh,value=phi.faceGrad,rank=1)},filename='prova.gz',extension='.gz')
>>>> 
>>>> which preserves the FaceVariable character.
>>>> 
>>>> Merry Christmas!
>>>> 
>>>> Marcel
>>>> 
>>>> 
>>>> 
>>>> El 19/12/19 a les 19:04, Keller, Trevor (Fed) via fipy ha escrit:
>>>> 
>>>>> The error message indicates that `dump.read` got something unexpected
>>>>> -- namely, a `value` field -- and threw.
>>>>> 
>>>>> Naïvely, dumping `phi.faceGrad.value` instea dof `phi.faceGrad`
>>>>> appears to do the trick.
>>>>> 
>>>>> 
>>>>> 
>>>> -- 
>>>> Dr. Marcel Aguilella-Arzo
>>>> Professor Titular d'Universitat, Física Aplicada
>>>> Coordinador de la Subespecialitat de CCEETT del Màster en Professor 
>>>> d'Educació Secundària
>>>> Departament de Física
>>>> Escola Superior de Tecnologia i Ciències Experimentals
>>>> Universitat Jaume I
>>>> Av. Sos Baynat, s/n
>>>> 12071 Castelló de la Plana (Spain)
>>>> +34 964 728 046
>>>> 
>>>> 
>>>> a...@uji.es
>>>> 
>>>> ___
>>>> 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
>>> ]
>>> 
>> -- 
>> Dr. Marcel Aguilella-Arzo
>> Professor Titular d'Universitat, Física Aplicada
>> Coordinador de la Subespecialitat de CCEETT del Màster en Professor 
>> d'Educació Secundària
>> Departament de Física
>> Escola Superior de Tecnologia i Ciències Experimentals
>> Universitat Jaume I
>> Av. Sos Baynat, s/n
>> 12071 Castelló de la Plana (Spain)
>> +34 964 728 046
>> 
>> a...@uji.es
>> ___
>> 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 ]


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

Re: Problem in dump.write for vector variables

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Thank you for the feedback. I'm inclined to agree.

- Jon

> On Jan 9, 2020, at 3:47 AM, Marcel UJI (IMAP)  wrote:
> 
> Hi Jonathan
> 
> Sorry by my late reply
> 
> I think that the second one would be enough as I only need to read this data 
> later for further processing. Actually this is not much an issue, as I can 
> simply save phi and later recompute phi.faceGrad, which is also much more 
> economic in terms of storage.
> 
> Thank you anyway for spending some time on this
> 
> Marcel
> 
> 
> 
> El 20/12/19 a les 16:27, Guyer, Jonathan E. Dr. (Fed) via fipy ha escrit:
>> Glad you found a solution, Marcel.
>> 
>> The issue is that a FaceGradVariable doesn't pickle itself properly. It 
>> stores the state for a generic FaceVariable, but then it doesn't know how to 
>> rebuild itself from that.
>> 
>> It either should 
>> - pickle the correct information, which would also involve pickling phi
>> OR
>> - pickle itself as a plain FaceVariable, losing connection to phi on 
>> unpickling (which is what your solution does)
>> 
>> Do you have an opinion on which behavior you'd like?
>> 
>> 
>>> On Dec 20, 2019, at 2:35 AM, Marcel UJI (IMAP) 
>>>  wrote:
>>> 
>>> Thank you Trevor,
>>> 
>>> This works, but it saves the array values only. 
>>> 
>>> I found an alternative solution with:
>>> 
>>> dump.write({'E' : 
>>> FaceVariable(mesh=mesh,value=phi.faceGrad,rank=1)},filename='prova.gz',extension='.gz')
>>> 
>>> which preserves the FaceVariable character.
>>> 
>>> Merry Christmas!
>>> 
>>> Marcel
>>> 
>>> 
>>> 
>>> El 19/12/19 a les 19:04, Keller, Trevor (Fed) via fipy ha escrit:
>>> 
>>>> The error message indicates that `dump.read` got something unexpected
>>>> -- namely, a `value` field -- and threw.
>>>> 
>>>> Naïvely, dumping `phi.faceGrad.value` instea dof `phi.faceGrad`
>>>> appears to do the trick.
>>>> 
>>>> 
>>>> 
>>> -- 
>>> Dr. Marcel Aguilella-Arzo
>>> Professor Titular d'Universitat, Física Aplicada
>>> Coordinador de la Subespecialitat de CCEETT del Màster en Professor 
>>> d'Educació Secundària
>>> Departament de Física
>>> Escola Superior de Tecnologia i Ciències Experimentals
>>> Universitat Jaume I
>>> Av. Sos Baynat, s/n
>>> 12071 Castelló de la Plana (Spain)
>>> +34 964 728 046
>>> 
>>> 
>>> a...@uji.es
>>> 
>>> ___
>>> 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
>>  ]
>> 
> -- 
> Dr. Marcel Aguilella-Arzo
> Professor Titular d'Universitat, Física Aplicada
> Coordinador de la Subespecialitat de CCEETT del Màster en Professor 
> d'Educació Secundària
> Departament de Física
> Escola Superior de Tecnologia i Ciències Experimentals
> Universitat Jaume I
> Av. Sos Baynat, s/n
> 12071 Castelló de la Plana (Spain)
> +34 964 728 046
> 
> a...@uji.es
> ___
> 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: Problem in dump.write for vector variables

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Glad you found a solution, Marcel.

The issue is that a FaceGradVariable doesn't pickle itself properly. It stores 
the state for a generic FaceVariable, but then it doesn't know how to rebuild 
itself from that.

It either should 
- pickle the correct information, which would also involve pickling phi
OR
- pickle itself as a plain FaceVariable, losing connection to phi on unpickling 
(which is what your solution does)

Do you have an opinion on which behavior you'd like?

> On Dec 20, 2019, at 2:35 AM, Marcel UJI (IMAP)  wrote:
> 
> Thank you Trevor,
> 
> This works, but it saves the array values only. 
> 
> I found an alternative solution with:
> 
> dump.write({'E' : 
> FaceVariable(mesh=mesh,value=phi.faceGrad,rank=1)},filename='prova.gz',extension='.gz')
> 
> which preserves the FaceVariable character.
> 
> Merry Christmas!
> 
> Marcel
> 
> 
> 
> El 19/12/19 a les 19:04, Keller, Trevor (Fed) via fipy ha escrit:
>> The error message indicates that `dump.read` got something unexpected
>> -- namely, a `value` field -- and threw.
>> 
>> Naïvely, dumping `phi.faceGrad.value` instea dof `phi.faceGrad`
>> appears to do the trick.
>> 
>> 
> -- 
> Dr. Marcel Aguilella-Arzo
> Professor Titular d'Universitat, Física Aplicada
> Coordinador de la Subespecialitat de CCEETT del Màster en Professor 
> d'Educació Secundària
> Departament de Física
> Escola Superior de Tecnologia i Ciències Experimentals
> Universitat Jaume I
> Av. Sos Baynat, s/n
> 12071 Castelló de la Plana (Spain)
> +34 964 728 046
> 
> a...@uji.es
> ___
> 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: Need help to set up the model

[Guyer, Jonathan E. Dr. (Fed) via fipy]

[note: I sent this to Mohammad more than a week ago and only learned now that 
it didn't go to the list]

Mohammad -

A couple of things:

- dc/dn = 0 is *not* a no flux condition. This is a really common assumption, 
and it's really wrong when there's strong convection. Your flux is $U_f \phi - 
D \nabla \phi$. 

- FiPy is a cell-centered finite volume solver. It's solving the divergence 
theorem on every cell. As a result, no flux boundary conditions are the 
default. Not only do you not need to set a constraint, any constraint you set 
will probably cause the boundaries to *not* be no flux.

Resolving these issues don't fix your problem, though. Ultimately, I think 
you're seeing phi exceed 200 because Uf is not divergence-free. You can see 
this by declaring a viewer

>>> viewer = fp.Viewer(vars=Uf.divergence, datamin=-0.0001, datamax=0.0001)

The divergence at the outlet river is not a problem, but everywhere else, it's 
saying that your lake water is compressible.

As far as I understand your script and data file, this is happening because 
FakeLake_SED_WU_Test.nc contains a 3D flow field and you're approximating it as 
a 2D field by averaging over the six depth layers. Even so averaged, there are 
still vertical flows, which amount to sources and sinks when you project it in 
2D. These sources and sinks seem particularly strong around the neck of "top 
river", which is where phi is going high. 

Frankly, I would just model the 3D flow; it's only 6x the cells you're modeling 
right now. Hopefully the full 3D flow data set is divergence free.

Other than that:

- I would only constrain phi.faceGrad to zero at the outlet river

- Ideally, your inlet and outlet masks should be defined parametrically or, 
even better, be explicitly identified by your mesh generator. "mask2 = (YY < 
4692200)" grabs a little bit of the bottom left river as well as some of the 
"bank" of the bottom right river. I'm not positive, but I think it doesn't 
completely capture the inlet of the bottom right river. I don't know what SMS 
provides, but you should try to make it tell you where the boundaries are, 
rather than hard wiring things like "- 50" and "< 4692200".

- Don't redefine the constraints and equation at every time step. It definitely 
slows things down, and probably leaks memory, too.

- I'm not sure if it matters, but the normal component of Uf should be zero on 
the exterior boundaries, but not at the river inlet/outlets.

- Jon

> On Nov 24, 2019, at 3:59 PM, Mohammad Madani  wrote:
> 
> Thank you for helping me with the mesh. 
> Please find attached files. I created the mesh and set up the model. 
> Regarding the boundary condition I have three conditions. 
> 
> 1 - no flux in all exterior faces (dc/dn = 0) except in input rivers. 
> 2 - constant concentration of 200 in top river 
> 3- constant concentration of 100 in small river in bottom right. 
> 
> I created those boundary conditions like this: 
> XX, YY = mesh.faceCenters
> mask = YY > np.max(YY) - 50  # top river
> mask2 = YY < 4692200 # bottom right river 
> phi.faceGrad.constrain(0., where=mesh.exteriorFaces)  # no flux condition
> phi.constrain(200., where=mesh.exteriorFaces & mask)
> phi.constrain(100., where=mesh.exteriorFaces & mask2)
> 
> Are they correct? 
> I notice there is a problem. With this inputs I should not have concentration 
> above 200 in my domain however I got values around 250-280 ? 
> 
> I somehow found out what the problem maybe is but I cannot fix it. It is 
> related to the convection coefficient or field velocities. if I use constant 
> (-1 , -1 ) in line 156 !
> 
> U_t = -1* np.ones(shape=(2, mesh.numberOfFaces))
> Uf.setValue(U_t)
> the model will run without getting any value higher than 200 but when I use 
> the actual Ux and Uy component of velocities, it gives me unrealistic values. 
> Could you please help me to fix this.
> 
> Attached are my code and one nc file that contains mesh node and element 
> information, temperature, and velocity components. 
> 
> 
> Thanks
> Mohammad 
> 
> -- Original Message --
> From: "Guyer, Jonathan E. Dr. (Fed) via fipy" 
> To: "FIPY" 
> Sent: 2019-11-22 11:30:19 AM
> Subject: Re: Need help to set up the model
> 
>> Mohammad -
>> 
>> Welcome to FiPy.
>> 
>> It's not a problem to mix triangles and quadrilaterals. FiPy is designed for 
>> this. The complication is that FiPy constructs cells from faces and faces 
>> are defined by vertices (nodes), so we need to reconstruct the face 
>> definitions from your cell_node_id.
>> 
>> Cribbing from gmshMesh.py:
>> 
>> import fipy as fp
>> from fipy.meshes.mesh2D import Mesh2D
>> from fipy.tools impor

Re: Need help to set up the model

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Mohammad -

Welcome to FiPy.

It's not a problem to mix triangles and quadrilaterals. FiPy is designed for 
this. The complication is that FiPy constructs cells from faces and faces are 
defined by vertices (nodes), so we need to reconstruct the face definitions 
from your cell_node_id.

Cribbing from gmshMesh.py:

import fipy as fp
from fipy.meshes.mesh2D import Mesh2D
from fipy.tools import numerix as nx

node_coordinates = fp.numerix.array(
((0., 0.),
 (1., 0.),
 (0., 1.),
 (1., 1.),
 (2., 0.),
 (3., 0.),
 (2., 1.),
 (3., 1.),
 (2., 2.),
 (3., 2.)
)
)

cell_node_id = fp.numerix.MA.masked_less((
(0, 1, 2, -1),
(1, 3, 2, -1),
(1, 4, 6, 3),
(4, 5, 7, -1),
(4, 7, 6, -1),
(6, 7, 9, 8)
), value=0.)

currNumFaces = 0
cellsToFaces = nx.ones(cell_node_id.shape, long) * -1
facesDict= {}
uniqueFaces  = []

for cellIdx, cell in enumerate(cell_node_id):
cell = cell.compressed()
faces = fp.numerix.concatenate((cell[..., nx.newaxis], 
fp.numerix.roll(cell, -1)[..., 
nx.newaxis]), 
   axis=1)
for faceIdx, face in enumerate(faces):
keyStr = ' '.join([str(x) for x in sorted(face)])

if keyStr in facesDict:
cellsToFaces[cellIdx][faceIdx] = facesDict[keyStr]
else: # new face
facesDict[keyStr] = currNumFaces
cellsToFaces[cellIdx][faceIdx] = currNumFaces
uniqueFaces.append(list(face))
currNumFaces += 1

# pad short faces with -1
maxFaceLen = max([len(f) for f in uniqueFaces])
uniqueFaces = [[-1] * (maxFaceLen - len(f)) + f for f in uniqueFaces]

facesToVertices = nx.array(uniqueFaces, dtype=int)

mesh = Mesh2D(vertexCoords=node_coordinates.swapaxes(0, 1).copy('C'),
  faceVertexIDs=facesToVertices.swapaxes(0, 1)[::-1],
  cellFaceIDs=cellsToFaces.swapaxes(0, 1).copy('C'))



In order to help with the boundary conditions, I need to know more about how 
define them, both their location and their values. 

- Jon

> On Nov 21, 2019, at 10:30 PM, Mohammad Madani  wrote:
> 
> Hello Everyone, 
> I sent below email to Dr. Guyer and he advised me to join the mailing list 
> and bring my questions here. Thank you!
> 
> Attached is a python file that I tried to modify one of the examples based on 
> my need. 
> First of all, I have a big problem in creating my mesh. I could not find how 
> to import my mesh to Fipy from the manual. Would you please help me with 
> that. The one showed in the attached file is just a template and it is not my 
> mesh. For my mesh, I have node_coordinates and cell_node_id: The mesh was 
> created using SMS software.  
> node_coordinates:
> array([[ 360980. , 4709150. ],
>[ 361720. , 4709170. ],
>[ 360610. , 4709140. ],
>...,
>[ 354182. , 4692112. ],
>[ 353605. , 4692098.2],
>[ 353914. , 4691819. ]])
> 
> cell_node_id: 
> array([[   0,3,4,   --],
>[   2,7,3,0],
>[   5,1,4,9],
>...,
>[1005, 1009, 1011, 1008],
>[1006, 1010, 1012, 1009],
>[1013, 1011, 1009, 1012]])
> 
> my mesh has both triangles and quadrilateral cells.  if that makes problem I 
> can create my mesh just with triangles
> 
> After creating my mesh, I know how to set up the model as I did in the 
> attached file, but still I don't know how to set up Boundary Condition. from 
> node_string 1 and 2 (below figure), variable concentration over time 
> introduced to the lake. 
> 
> Any comments and help would be appreciated. 
> 
> Thanks
> Mohammad 
> 
> -- Forwarded Message --
> From: "Mohammad Madani" 
> To: jonathan.gu...@nist.gov
> Sent: 2019-11-14 11:50:31 AM
> Subject: Need help to set up the model
> 
> Hello Dr. Guyer
> I am PhD student from University of Windsor, Canada. I am working on 
> microbial modelling in the lake and would like to use Fipy to solve the E. 
> coli transport equation. the governing equation is 
> 
> 
> 
> where C is the E. coli concentration and k is the decay rate. k is function 
> of temperature and solar radiation which I have the time series of solar 
> radiation. I also have water temperature for each cell from the hydrodynamic 
> model. 
> lets say the k value can be calculate as: 
> 
> k = k0 * 10 ^( 20 - T) * Solar_Radiation
> 
> where k0 is constant and T is temperature. 
> 
> I also have time series of velocities (u, v and w) from hydrodynamic model 
> for each cell. Here is my mesh: 
> 
> which node-string  1 and 2 are input and 3 is the output of the lake. E coli 
> concentration from the inputs can be provided as time series too. 
> Can I solve this problem with Fipy? would you please help me to set up the 
> python code to do it. 
> 
> looking forward to hear from you soon. 
> Thank you, 
> 
>
> Mohammad Madani
> PhD Candidate
> Department of Civil & Environmental Eng.
> CEI, Room 3084, 

Re: Problems using Grid2D

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Thanks for this, Martin. 

The .plot() and ._plot() methods of many of the Viewers can give an idea on how 
a particular CellVariable should be transformed into physical space.

> On Sep 29, 2019, at 11:01 AM, Martinus WERTS  
> wrote:
> 
> Dear Justin,
> 
> Independently of the mesh, the cells in FiPy are stored in a 1D array (a
> vector).
> 
> The coordinates of each cell are also available as 1D arrays. E.g., for
> a "UniformGrid3D" mesh, one can obtain these as
> 
> X, Y, Z = mesh.cellCenters
> 
> In the case of structured meshes, it is possible (but perhaps not
> desirable) to create a 'reshaped' view on these 1D vectors. For 3D (but
> should be adaptable for 2D):
> 
> X.reshape(Nz, Ny, Nx)
> Y.reshape(Nz, Ny, Nx)
> Z.reshape(Nz, Ny, Nx)
> CellVariable.value.reshape(Nz, Ny, Nx)
> 
> Nz, Ny, and Nx are the number of cells in the z, y, and x direction
> respectively.
> 
> Best wishes,
> Martin
> 
> 
> 
> On 27/09/2019 20:03, Guyer, Jonathan E. Dr. (Fed) via fipy wrote:
>>> On Sep 26, 2019, at 7:29 PM, Justin Pothoof  wrote:
>>> 
>>> I noticed that if i print(shape(CellVariable.value)) after defining a 
>>> CellVariable I get the output (2000,) for example.. which isn't a 2D array.
>> FiPy is designed for unstructured meshes, so there is no internal structure 
>> to the Variable data. Geometry and topology is defined by the Mesh.
>> ___
>> 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 ]


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

Re: Problems using Grid2D

[Guyer, Jonathan E. Dr. (Fed) via fipy]

> On Sep 26, 2019, at 7:29 PM, Justin Pothoof  wrote:
> 
> I noticed that if i print(shape(CellVariable.value)) after defining a 
> CellVariable I get the output (2000,) for example.. which isn't a 2D array.

FiPy is designed for unstructured meshes, so there is no internal structure to 
the Variable data. Geometry and topology is defined by the Mesh.
___
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]

Re: Problems using Grid2D

[Guyer, Jonathan E. Dr. (Fed) via fipy]

dx needs to be a float: `dx = 1.`

This doesn't always seem to be true, but it is often enough that we should 
figure out how to fix it or raise an error.

https://github.com/usnistgov/fipy/issues/672

> On Sep 26, 2019, at 7:29 PM, Justin Pothoof  wrote:
> 
> Hello,
> 
> I'm trying to set up a 2D diffusion problem.  I noticed that if i 
> print(shape(CellVariable.value)) after defining a CellVariable I get the 
> output (2000,) for example.. which isn't a 2D array.  I decided to test the 
> 2D diffusion example provided, but I encounter the "RuntimeError: Factor is 
> exactly singular" and it also will not plot. It is copied straight from the 
> mesh.20x20 example, so I'm not sure why it will not run.
> 
> from fipy import CellVariable, Grid2D, Viewer, TransientTerm, DiffusionTerm
> from fipy.tools import numerix
> 
> nx = 20
> ny = nx
> dx = 1
> dy = dx
> L = dx * nx
> mesh = Grid2D(dx=dx, dy=dy, nx=nx, ny=ny)
> 
> phi = CellVariable(name="solution variable", mesh=mesh, value=0.)
> D = 1
> eq = TransientTerm() == DiffusionTerm(coeff=D)
> 
> valueTopLeft = 0
> valueBottomRight = 1
> 
> X, Y = mesh.faceCenters
> facesTopLeft = ((mesh.facesLeft & (Y > L / 2)) | (mesh.facesTop & (X < L / 
> 2)))
> facesBottomRight = ((mesh.facesRight & (Y < L / 2)) | (mesh.facesBottom & (X 
> > L / 2)))
> 
> phi.constrain(valueTopLeft, facesTopLeft)
> phi.constrain(valueBottomRight, facesBottomRight)
> 
> 
> if __name__ == '__main__':
> viewer = Viewer(vars=phi, datamin=0., datamax=1.)
> viewer.plot()
> 
> timeStepDuration = 10 * 0.9 * dx**2 / (2 * D)
> steps = 10
> for step in range(steps):
> eq.solve(var=phi, dt=timeStepDuration)
> if __name__ == '__main__':
> viewer.plot()
> Justin Pothoof
> The University of Washington - Department of Chemistry
> Pre-Candidacy PhD Student
> Ginger Group
> ___
> 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: Boundary condition problem

[Guyer, Jonathan E. Dr. (Fed) via fipy]

umpy as np
> import matplotlib.pyplot as plt
> from fipy import Variable, FaceVariable, CellVariable, Grid1D, 
> ExplicitDiffusionTerm, TransientTerm, DiffusionTerm, Viewer, 
> ImplicitSourceTerm, ConvectionTerm
> from scipy import special
> 
> a1,b1,c1,a2,b2,c2 = [1.07114255e+00,  6.50014631e+05, -4.51527221e+00,  
> 1.04633414e+00,
>   1.99708312e+05, -1.52479293e+00]
> 
> 
> q = 1.602e-19#Elementary Charge
> pini = 154.1581560721245/q   #m^-3
> nini = 134.95618729/q   #m^-3
> 
> k1 = 1.8
> p1 = 17
> k2 = 17
> p2 = 1.8
> 
> l = 0.134901960784314 #Length of system in m
> nx = 134  #Number of cells in system
> dx = l/nx #Length of each cell in m
> x = np.linspace(0,l,nx)   #Array to calculate initial values in functions 
> below
> 
> 
> epsilon_r = 25#Relative permittivity of system
> epsilon = epsilon_r*8.854e-12 #Permittivity of system  C/V*m
> kb = 1.38e-23 #J/K
> T = 298   #K
> f = kb*T/q#Volts
> mu_n =1.1e-09/1  #m^2/V*s
> mu_p =1.1e-09/1  #m^2/V*s
> Dn = f * mu_n   #m^2/s
> Dp = f * mu_p #m^2/s
> 
> # k_rec = q*(mu_n+mu_p)/(2*epsilon)
> k_rec = 0.
> 
> # y01 = np.zeros(nx)
> # y01[10:20] = 1e21
> #
> # y02 = np.zeros(nx)
> # y02[110:120] = 1e21
> 
> mesh = Grid1D(dx=dx, nx=nx) #Establish mesh in how many dimensions necessary
> 
> Pion = CellVariable(mesh=mesh, name='Positive ion Charge Density', 
> value=y01(x))
> Nion = CellVariable(mesh=mesh, name='Negative ion Charge Density', 
> value=y02(x))
> potential = CellVariable(mesh=mesh, name='Potential', value=0.)
> 
>  Equations set-up 
> 
> #In English:  dPion/dt = -1/q * divergence.Jp(x,t) - k_rec * Nion(x,t) * 
> Pion(x,t) where
> # Jp = q * mu_p * E(x,t) * Pion(x,t) - q * Dp * grad.Pion(x,t)
>  and E(x,t) = -grad.potential(x,t)
> # Continuity Equation
> Pion.equation = TransientTerm(coeff=1., var=Pion) == mu_p * 
> ConvectionTerm(coeff=potential.faceGrad, var=Pion)+Dp*DiffusionTerm(coeff=1., 
> var=Pion)
> 
> #In English:  dNion/dt = 1/q * divergence.Jn(x,t) - k_rec * Nion(x,t) * 
> Pion(x,t)   where
> # Jn = q * mu_n * E(x,t) * Nion(x,t) - q * Dn * grad.Nion(x,t)
>  and E(x,t) = -grad.potential(x,t)
> # Continuity Equation
> Nion.equation = TransientTerm(coeff=1., var=Nion) == -mu_n * 
> ConvectionTerm(coeff=potential.faceGrad, var=Nion)+Dn*DiffusionTerm(coeff=1., 
> var=Nion)
> 
> #In English:  d^2potential/dx^2 = q/epsilon * Charge_Density  and 
> Charge Density= Pion -Nion
> # Poisson's Equation
> potential.equation = DiffusionTerm(coeff=1., var=potential) == 
> (q/epsilon)*(Pion-Nion)
> 
> 
> ### Boundary conditions ###
> # Fipy is defaulted to be no-flux, so we only need to constrain potential
> potential.constrain(0., where=mesh.exteriorFaces)
> 
> ### Solve Equations ###
> eq = Pion.equation & Nion.equation & potential.equation
> 
> steps = 1000
> timestep = 0.5
> for step in range(steps):
> eq.solve(dt=timestep )
> if (step%1000)==0:
> viewer = Viewer(vars=(potential,), datamin= -2., datamax=2.)
> # viewer = Viewer(vars=(Pion,), datamin=0., datamax=10e21)
> # viewer = Viewer(vars=(Nion,), datamin=0., datamax= 4e21)
> # plt.pause(1)
> viewer.plot()
> # plt.autoscale()
> 
> 
> On Tue, Aug 13, 2019 at 1:10 PM Guyer, Jonathan E. Dr. (Fed) 
>  wrote:
> In my experience, Poisson's equation must be "grounded" in at least one 
> location. You might try constraining the value of V on just one boundary.
> 
> You might also try solving for a ConvectionTerm on P, rather than a 
> DiffusionTerm on V, e.g.
>   ConvectionTerm(coeff=V_variable.faceGrad, var=P_variable)
> instead of
>   DiffusionTerm(coeff=P_variable, var=V_variable)
> 
> Generally, though, I hate the drift-diffusion equations and find them 
> challenging to solve.
> 
> 
> From: Fangyuan Jiang 
> Sent: Tuesday, August 13, 2019 1:11 PM
> To: Guyer, Jonathan E. Dr. (Fed); FIPY
> Subject: Re: Boundary condition problem
> 
> Thanks Jon for the quick response. I tried to remove the boundary constrain 
> before, but kept showing "RuntimeError: Factor is exactly singular", I 
> couldn't fix that problem by giving different "dt", and don't know what 
> exactly is the problem. Could you please give me some advice?
> 
> thanks a lot
> Jiang
> 
> On Tue, Aug 13, 2019 at 9:53 AM Guyer, Jonathan E. Dr. (Fed) via fipy 
> mailto:fipy@nist.gov>> wro

Re: Boundary condition problem

[Guyer, Jonathan E. Dr. (Fed) via fipy]

In my experience, Poisson's equation must be "grounded" in at least one 
location. You might try constraining the value of V on just one boundary.

You might also try solving for a ConvectionTerm on P, rather than a 
DiffusionTerm on V, e.g.
  ConvectionTerm(coeff=V_variable.faceGrad, var=P_variable)
instead of
  DiffusionTerm(coeff=P_variable, var=V_variable)

Generally, though, I hate the drift-diffusion equations and find them 
challenging to solve.


From: Fangyuan Jiang 
Sent: Tuesday, August 13, 2019 1:11 PM
To: Guyer, Jonathan E. Dr. (Fed); FIPY
Subject: Re: Boundary condition problem

Thanks Jon for the quick response. I tried to remove the boundary constrain 
before, but kept showing "RuntimeError: Factor is exactly singular", I couldn't 
fix that problem by giving different "dt", and don't know what exactly is the 
problem. Could you please give me some advice?

thanks a lot
Jiang

On Tue, Aug 13, 2019 at 9:53 AM Guyer, Jonathan E. Dr. (Fed) via fipy 
mailto:fipy@nist.gov>> wrote:
Jiang -

FiPy is no-flux by default, so if you apply no constraints, P should not flow 
out. By constraining P to be zero on the exteriorFaces, you guarantee that 
there will be a flux in our out of the external boundary.

- Jon


From: fipy-boun...@nist.gov<mailto:fipy-boun...@nist.gov> 
mailto:fipy-boun...@nist.gov>> on behalf of Fangyuan 
Jiang mailto:fyji...@uw.edu>>
Sent: Tuesday, August 13, 2019 12:25 PM
To: FIPY
Subject: Boundary condition problem

Good morning!
Recently, I start to use fipy to solve partial differential equations, but was 
stuck in the boundary conditions constrain. I want to constrain the variable 
P(x,t) within the system, but can't stop it from flowing out of the system. I 
tried all kinds of boundary condition in fipy, but all failed.

Below is the two coupled equations, with the code that I write, please correct 
me if I am wrong, I would be very grateful, since I don't have any friends who 
has used fipy to discuss with. Therefore, any of your suggestions would be much 
appreciated.

Best regards
Jiang
Graduate students of UW

Equations:
∇2V(x,t)=-a1* P(x, t)
dP(x, t)/dt = a2* ∇(∇V(x,t)*P(x,t))

boundary condition :
y01=np.zero(nx)
y01[30 :70]=1e21
P(x, t=0) = y01

L=1e-6,  nx=100,  dx= L/nx,  a1= 7.23164*e10,   a2=1.1e-13


import numpy as np
import matplotlib.pyplot as plt
from fipy import Variable, FaceVariable, CellVariable, Grid1D, TransientTerm, 
DiffusionTerm, Viewer, ConvectionTerm

L=1e-6
nx=100
dx= L/nx
a1=7.23164e-10
a2=1.1e-13

x = np.linspace(0, L, nx)
y01 = np.zeros(nx)
y01[30:70] = 1e21

mesh = Grid1D(dx=dx, nx=nx)

P_variable = CellVariable(mesh=mesh, name='Positive Charge Density', value= y01)
V_variable = CellVariable (mesh=mesh, name='potential', value=0.)

Eqn1 = DiffusionTerm(coeff=1, var=V_variable) == -a1 * P_variable
Eqn2 = TransientTerm(coeff=1, var=P_variable) == a2 * 
DiffusionTerm(coeff=P_variable, var=V_variable)

V_variable.constrain(0., mesh.exteriorFaces)
# P_variable.faceGrad.constrain(0., mesh.exteriorFaces)

eq = Eqn1 & Eqn2

steps = 1000
time_step = 0.1

for step in range(steps):
eq.solve(dt=time_step)
if step%1000==0:
viewer = Viewer(vars=(P_variable,), datamin=0, datamax=1.5e21)
# plt.pause(1)
viewer.plot()




___
fipy mailing list
fipy@nist.gov<mailto: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: Boundary condition problem

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Jiang -

FiPy is no-flux by default, so if you apply no constraints, P should not flow 
out. By constraining P to be zero on the exteriorFaces, you guarantee that 
there will be a flux in our out of the external boundary.

- Jon


From: fipy-boun...@nist.gov  on behalf of Fangyuan Jiang 

Sent: Tuesday, August 13, 2019 12:25 PM
To: FIPY
Subject: Boundary condition problem

Good morning!
Recently, I start to use fipy to solve partial differential equations, but was 
stuck in the boundary conditions constrain. I want to constrain the variable 
P(x,t) within the system, but can't stop it from flowing out of the system. I 
tried all kinds of boundary condition in fipy, but all failed.

Below is the two coupled equations, with the code that I write, please correct 
me if I am wrong, I would be very grateful, since I don't have any friends who 
has used fipy to discuss with. Therefore, any of your suggestions would be much 
appreciated.

Best regards
Jiang
Graduate students of UW

Equations:
∇2V(x,t)=-a1* P(x, t)
dP(x, t)/dt = a2* ∇(∇V(x,t)*P(x,t))

boundary condition :
y01=np.zero(nx)
y01[30 :70]=1e21
P(x, t=0) = y01

L=1e-6,  nx=100,  dx= L/nx,  a1= 7.23164*e10,   a2=1.1e-13


import numpy as np
import matplotlib.pyplot as plt
from fipy import Variable, FaceVariable, CellVariable, Grid1D, TransientTerm, 
DiffusionTerm, Viewer, ConvectionTerm

L=1e-6
nx=100
dx= L/nx
a1=7.23164e-10
a2=1.1e-13

x = np.linspace(0, L, nx)
y01 = np.zeros(nx)
y01[30:70] = 1e21

mesh = Grid1D(dx=dx, nx=nx)

P_variable = CellVariable(mesh=mesh, name='Positive Charge Density', value= y01)
V_variable = CellVariable (mesh=mesh, name='potential', value=0.)

Eqn1 = DiffusionTerm(coeff=1, var=V_variable) == -a1 * P_variable
Eqn2 = TransientTerm(coeff=1, var=P_variable) == a2 * 
DiffusionTerm(coeff=P_variable, var=V_variable)

V_variable.constrain(0., mesh.exteriorFaces)
# P_variable.faceGrad.constrain(0., mesh.exteriorFaces)

eq = Eqn1 & Eqn2

steps = 1000
time_step = 0.1

for step in range(steps):
eq.solve(dt=time_step)
if step%1000==0:
viewer = Viewer(vars=(P_variable,), datamin=0, datamax=1.5e21)
# plt.pause(1)
viewer.plot()




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

Re: Drift Diffusion Equation Setup

[Guyer, Jonathan E. Dr. (Fed) via fipy]

By doing that, you're double counting.

DiffusionTerm(coeff=-mu_p * Pion, var=potental) represents the mathematical
$\nabla\cdot(-\mu_p P_{ion} \nabla V)$
(or divergence.(-mu_p * grad.potential(x,t) * Pion(x,t)) if you prefer).

ConvectionTerm(coeff=-mu_p * potential.faceGrad, var=Pion) *also* represents 
the mathematical $\nabla\cdot(-(\mu_p \nabla V) P_{ion}
\equiv \nabla\cdot(-\mu_p P_{ion}  \nabla V)$

In DiffusionTerm form, it is implicit in potential. In ConvectionTerm form, it 
is implicit in Pion, but either one represents the drift portion of the current 
density and both should not be be used together.


From: Justin Pothoof 
Sent: Friday, August 9, 2019 8:24 PM
To: Guyer, Jonathan E. Dr. (Fed); FIPY
Subject: Re: Drift Diffusion Equation Setup

When taking the divergence of current density:  divergence.(-mu_p * 
grad.potential(x,t) * Pion(x,t)) would the divergence not also be applied to 
the Pion term, since it is also a function of x. I essentially applied the 
product rule to obtain the `Pion * potential.faceGrad.divergence`  part, which 
in hindsight should have just been a DiffusionTerm.  This is how I would derive 
the  divergence.(-mu_p * grad.potential(x,t) * Pion(x,t)) as = 
DiffusionTerm(coeff=-mu_p * Pion, var=potential) + ConvectionTerm(-mu_p * 
potential.faceGrad, var = Pion)

Which would just be the drift term for the current density. So, the entire 
divergence.(Jp) would be:
DiffusionTerm(coeff=-mu_p * Pion, var=potential) + ConvectionTerm(-mu_p * 
potential.faceGrad, var = Pion)  - DiffusionTerm(coeff=Dp, var=Pion)
to include the diffusion part.

Please correct me if this is an incorrect understanding, and thank you so much!

Justin Pothoof
The University of Washington - Department of Chemistry
Pre-Candidacy PhD Student
Ginger Group


On Fri, Aug 9, 2019 at 1:36 PM Guyer, Jonathan E. Dr. (Fed) via fipy 
mailto:fipy@nist.gov>> wrote:
Justin -

A couple of things:
- Charge Density is not Pion + Nion, it's Pion - Nion
- What are the terms `Pion * potential.faceGrad.divergence` in Pion.equation 
and `Nion * potential.faceGrad.divergence` in Nion.equation? I don't believe 
they should be there.
- Your equations are really not coupled. Pion.equation is an implicit function 
of only Pion, Nion.equation is an implicit function of only Nion, and 
potential.equation is an implicit function of only potential. Binding these 
equations together with `&` does not gain you anything. Coupling comes from 
having implicit parts more than one variable in your equations, e.g., k_rec * 
Nion(x,t) * Pion(x,t) could be ImplicitSourceTerm(coeff=k_rec*Nion) in 
Pion.equation and ImplicitSourceTerm(coeff=k_rec*Pion) in Nion.equation. 
Likewise, divergence.(-mu_p * grad.potential(x,t) * Pion(x,t)) can either be 
ConvectionTerm(coeff=-mu_p * potential.faceGrad, var=Pion) or it can be 
DiffusionTerm(coeff=-mu_p * Pion, var=potential).
- Boundary conditions in FiPy are no-flux by default, so there's no need to 
constrain Pion and Nion.

- Jon


From: Justin Pothoof mailto:jpoth...@uw.edu>>
Sent: Friday, August 9, 2019 2:51 PM
To: Guyer, Jonathan E. Dr. (Fed); FIPY
Subject: Re: Drift Diffusion Equation Setup

Hi Jon,

I've been continuing to work on my problem. I've implemented the divergence of 
the current density mathematically into the positive charge and negative charge 
density equations. Now, I'm encountering issues with the boundary conditions.. 
the charges should be flowing towards the center of the system, and ultimately 
recombine, but the issues I'm seeing is that the charges are flowing out of the 
region.  I would like to keep all of the charges confined to the system and 
prevent them from flowing out of the left and right boundaries. I've tried 
implementing neumann boundaries using Pion.faceGrad.constrain(0., 
where=mesh.exteriorFaces) and the negative charge version, but I'm still seeing 
the charges flow mostly out of the system.  I would appreciate any help!

Thank you,
Justin


import numpy as np
import matplotlib.pyplot as plt
from scipy import special
from fipy import Variable, FaceVariable, CellVariable, Grid1D, 
ExplicitDiffusionTerm, TransientTerm, DiffusionTerm, Viewer, 
ImplicitSourceTerm, ConvectionTerm
from fipy.tools import numerix

##
#''' SET-UP PARAMETERS '''
##

a1,b1,c1,a2,b2,c2 = [1.07114255e+00,  6.50014631e+05, -4.51527221e+00,  
1.04633414e+00,
  1.99708312e+05, -1.52479293e+00]
# Parameters for sum of sines fit (Potential fit)

#a = -3930.03590805
#b, c = 3049.38274411, -4.01434474
# Parameters for exponential fit (Charge Density)  Not used yet

q = 1.602e-19#Elementary Charge

pini = 154.1581560721245/q   #m^-3

nini = -134.95618729/q   #m^-3


k1 = 1.8

p1 = 17

k2 = 17

p2 = 1.8
# Parameters for charge density

Re: Drift Diffusion Equation Setup

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Justin -

A couple of things:
- Charge Density is not Pion + Nion, it's Pion - Nion
- What are the terms `Pion * potential.faceGrad.divergence` in Pion.equation 
and `Nion * potential.faceGrad.divergence` in Nion.equation? I don't believe 
they should be there.
- Your equations are really not coupled. Pion.equation is an implicit function 
of only Pion, Nion.equation is an implicit function of only Nion, and 
potential.equation is an implicit function of only potential. Binding these 
equations together with `&` does not gain you anything. Coupling comes from 
having implicit parts more than one variable in your equations, e.g., k_rec * 
Nion(x,t) * Pion(x,t) could be ImplicitSourceTerm(coeff=k_rec*Nion) in 
Pion.equation and ImplicitSourceTerm(coeff=k_rec*Pion) in Nion.equation. 
Likewise, divergence.(-mu_p * grad.potential(x,t) * Pion(x,t)) can either be 
ConvectionTerm(coeff=-mu_p * potential.faceGrad, var=Pion) or it can be 
DiffusionTerm(coeff=-mu_p * Pion, var=potential).
- Boundary conditions in FiPy are no-flux by default, so there's no need to 
constrain Pion and Nion.

- Jon


From: Justin Pothoof 
Sent: Friday, August 9, 2019 2:51 PM
To: Guyer, Jonathan E. Dr. (Fed); FIPY
Subject: Re: Drift Diffusion Equation Setup

Hi Jon,

I've been continuing to work on my problem. I've implemented the divergence of 
the current density mathematically into the positive charge and negative charge 
density equations. Now, I'm encountering issues with the boundary conditions.. 
the charges should be flowing towards the center of the system, and ultimately 
recombine, but the issues I'm seeing is that the charges are flowing out of the 
region.  I would like to keep all of the charges confined to the system and 
prevent them from flowing out of the left and right boundaries. I've tried 
implementing neumann boundaries using Pion.faceGrad.constrain(0., 
where=mesh.exteriorFaces) and the negative charge version, but I'm still seeing 
the charges flow mostly out of the system.  I would appreciate any help!

Thank you,
Justin


import numpy as np
import matplotlib.pyplot as plt
from scipy import special
from fipy import Variable, FaceVariable, CellVariable, Grid1D, 
ExplicitDiffusionTerm, TransientTerm, DiffusionTerm, Viewer, 
ImplicitSourceTerm, ConvectionTerm
from fipy.tools import numerix

##
#''' SET-UP PARAMETERS '''
##

a1,b1,c1,a2,b2,c2 = [1.07114255e+00,  6.50014631e+05, -4.51527221e+00,  
1.04633414e+00,
  1.99708312e+05, -1.52479293e+00]
# Parameters for sum of sines fit (Potential fit)

#a = -3930.03590805
#b, c = 3049.38274411, -4.01434474
# Parameters for exponential fit (Charge Density)  Not used yet

q = 1.602e-19#Elementary Charge

pini = 154.1581560721245/q   #m^-3

nini = -134.95618729/q   #m^-3


k1 = 1.8

p1 = 17

k2 = 17

p2 = 1.8
# Parameters for charge density fit (Susi's fit)

l = 0.134901960784314 #Length of system in m

nx = 134  #Number of cells in system

dx = l/nx #Length of each cell in m

x = np.linspace(0,l,nx)   #Array to calculate initial values in functions below


epsilon_r = 25#Relative permittivity of system

epsilon = epsilon_r*8.854e-12 #Permittivity of system  C/V*m

kb = 1.38e-23 #J/K

T = 298   #K

f = kb*T/q#Volts

mu_n = 1.1e-09/1  #m^2/V*s

mu_p = 1.1e-09/1  #m^2/V*s

Dn = f * mu_n #m^2/s

Dp = f * mu_p #m^2/s

k_rec = q*(mu_n+mu_p)/(2*epsilon)*10
#k_rec = 0

#pini*np.exp(a*x)
#nini*np.exp(b*x+c)   #Equations for exponential charge density fits 
(Not Used Yet)





##
##''' INITIAL CONDITION FUNCTIONS '''#
##

def y01(x):
"""Initial positive ion charge density"""
return 
pini*((special.gamma(k1+p1))/(special.gamma(k1)*special.gamma(p1))*((x/l)**(k1-1))*(1-(x/l))**(p1-1))/7.3572

def y02(x):
""""Initial negative ion charge density"""
return 
nini*((special.gamma(k2+p2))/(special.gamma(k2)*special.gamma(p2))*((x/l)**(k2-1))*(1-(x/l))**(p2-1))/7.3572

def y03(x):
"""Initial potential"""
return a1*np.sin(b1*x+c1) + a2*np.sin(b2*x+c2)



mesh = Grid1D(dx=dx, nx=nx) #Establish mesh in how many dimensions necessary





##
#''' SETUP CELLVARIABLES AND EQUATIONS '''
##

#CellVariable - defines the variables that you want to solve for:

'''Initial v

Re: Is faceGrad at boundaries assumed zero by default, or only its component normal to the boundary?

[Guyer, Jonathan E. Dr. (Fed) via fipy]

No need to apologize. I'm glad you were able to find the information you were 
looking for.

As [noted 
here](https://www.ctcms.nist.gov/fipy/examples/diffusion/generated/examples.diffusion.mesh1D.html?highlight=gradient)
the normal component of the boundary gradients are zero by default.

You can see the non-zero tangential components in this simple example:
```
import fipy as fp
mesh = fp.Grid2D(nx=1, ny=2)
var = fp.CellVariable(mesh=mesh, value=[1, 2])
fp.Viewer(vars=var.faceGrad).plot()
```


From: fipy-boun...@nist.gov  on behalf of M.J. Bogdan 

Sent: Thursday, August 8, 2019 5:12 AM
To: FIPY
Subject: Re: Is faceGrad at boundaries assumed zero by default, or only its 
component normal to the boundary?

All right, I've found the information, so sorry for engaging you.

Best regards,

Michal

On 2019-08-03 14:47, M.J. Bogdan wrote:
> Hello,
>
> I am slightly confused by the default boundary Neumann condition of
> faceGrad. I have found a mention in one of the previous e-mail threads
> here that faceGrad is assumed 0 by default on mesh boundaries, for any
> variable (I have failed to locate any mention of this in the
> documentation, but will be happy to be pointed to a relevant piece
> there). Is that precisely correct? Or is only the faceGrad component
> normal to boundary that is set to 0 by default?
>
> Best regards,
>
> Michal
>
>
>
>
> ___
> 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 ]

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

Re: Drift Diffusion Equation Setup

[Guyer, Jonathan E. Dr. (Fed) via fipy]

A current density or flux is a rank-1 variable, typically defined on face 
centers. Your expression 

J_n = -mu_n * n.harmonicFaceValue * phi.faceGrad + D_n * n.faceGrad

appropriately declares a rank-1 FaceVariable.

If you attempt to assign this value to a CellVariable, FiPy complains because 
face centers don't coincide with cell centers.

Solution variables in FiPy must be CellVariable objects. This is fine, because 
you don't solve for J_n.

The intention of my earlier suggestion was that you should *mathematically* 
combine your expressions for J_n and dn/dt to obtain a 2nd order PDE for dn/dt 
in terms of CellVariables you know, like n, p, and V.

> On Jul 25, 2019, at 5:15 PM, Justin Pothoof  wrote:
> 
> Great, that makes a lot of sense!  
> 
> I've tried to define the current density as a CellVariable with the value J_n 
> = -mu_n * n.harmonicFaceValue * phi.faceGrad + D_n * n.faceGrad
> as I've seen you describe in the mailing list before.  But, I keep 
> encountering the error "ValueError: could not broadcast input array from 
> shape (135) into shape (134)" with my mesh defined as length of 134.
> 
> I believe this is caused by the harmonicFaceValue, though I am not sure? 
> 
> Would the following definition for current density also work:  J_p.value = 
> -mu_p * p * psi.arithmeticFaceValue.divergence + Dn * 
> p.aritmeticFaceValue.divergence
> 
> I apologize for the multiple questions and I'm very grateful for your help!
> Justin
> 
> On Thu, Jul 25, 2019 at 10:55 AM Guyer, Jonathan E. Dr. (Fed) via fipy 
>  wrote:
> Justin -
> 
> I would define a function that takes an argument x for each of your 
> analytical expressions, e.g.,
> 
> ```
> def y01(x):
> """Initial positive ion charge density"""
> return 
> pini*((special.gamma(k1+p1))/(special.gamma(k1)*special.gamma(p1))*((x/l)**(k1-1))*(1-(x/l))**(p1-1))/7.3572
> 
> def y02(x):
> """"Initial negative ion charge density"""
> return 
> nini*((special.gamma(k2+p2))/(special.gamma(k2)*special.gamma(p2))*((x/l)**(k2-1))*(1-(x/l))**(p2-1))/7.3572
> 
> def y03(x):
> """Initial potential"""
> return a1*np.sin(b1*x+c1) + a2*np.sin(b2*x+c2)
> ```
> 
> Then you can invoke these functions with either the linspace to generate 
> plots like you have, or with the mesh positions, to set the initial 
> conditions:
> 
> ```
> Pion.value = y01(mesh.x)
> Nion.value = y02(mesh.x)
> potential.value = y03(mesh.x)
> ```
> 
> - Jon
> 
> > On Jul 24, 2019, at 1:23 PM, Justin Pothoof  wrote:
> > 
> > Thank you Jon,
> > 
> > I will try writing it in one equation as you suggested.  Regarding the 
> > experimental data, I have an initial potential curve described by a sum of 
> > sines fit as well as initial positive/negative charge density curves 
> > described by a specific equation I'll show in a file.
> > 
> > Thanks for the help!
> > Justin
> > 
> > On Wed, Jul 24, 2019 at 6:06 AM Guyer, Jonathan E. Dr. (Fed) via fipy 
> >  wrote:
> > Justin -
> > 
> > What that error means is that if you write 'var=' for any Term, then you 
> > must write 'var=' for every Term.
> > 
> > In your equations:
> > 
> > ```
> > Pion.equation = TransientTerm() + k_rec * Pion * Nion + 
> > ConvectionTerm(coeff=1 / q, var=Jp) == 0
> > Nion.equation = TransientTerm() + k_rec * Pion * Nion + 
> > ConvectionTerm(coeff=-1 / q, var=Jn) == 0
> > potential.equation = DiffusionTerm(1 / q * epsilon) + Pion * Nion == 0
> > Jp.equation = ImplicitSourceTerm() + ConvectionTerm(coeff=-q * mu_p * Pion, 
> > var=potential) + ConvectionTerm(coeff=-q * Dp, var=Pion) == 0
> > Jn.equation = ImplicitSourceTerm() + ConvectionTerm(coeff=-q * mu_n * Nion, 
> > var=potential) + ConvectionTerm(coeff=q * Dn, var=Nion) == 0
> > ```
> > FiPy does not know what Variable TransientTerm() applies to in 
> > Pion.equation and Nion.equation, DiffusionTerm() in potential.equation, nor 
> > ImplicitSourceTerm() in Jp.equation and Jn.equation.
> > 
> > As a further point, you should not solve Pion.equation and Jp.equation 
> > separately nor Nion.equation/Jn.equation. Combine them for a single, second 
> > order PDE each for n and for p. You will want to take care that, e.g., the 
> > equation should not be taking the gradient (\nabla) of a vector (Jn), which 
> > would give you a tensor; rather, the expression should be divergence 
> > (\nabla\cdot) of a vector (Jn), giving a scalar.
> > 
> > As to comparing to your experimental data, I'd need to know what form it 
> > takes 

Re: Drift Diffusion Equation Setup

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Justin -

I would define a function that takes an argument x for each of your analytical 
expressions, e.g.,

```
def y01(x):
"""Initial positive ion charge density"""
return 
pini*((special.gamma(k1+p1))/(special.gamma(k1)*special.gamma(p1))*((x/l)**(k1-1))*(1-(x/l))**(p1-1))/7.3572

def y02(x):
""""Initial negative ion charge density"""
return 
nini*((special.gamma(k2+p2))/(special.gamma(k2)*special.gamma(p2))*((x/l)**(k2-1))*(1-(x/l))**(p2-1))/7.3572

def y03(x):
"""Initial potential"""
return a1*np.sin(b1*x+c1) + a2*np.sin(b2*x+c2)
```

Then you can invoke these functions with either the linspace to generate plots 
like you have, or with the mesh positions, to set the initial conditions:

```
Pion.value = y01(mesh.x)
Nion.value = y02(mesh.x)
potential.value = y03(mesh.x)
```

- Jon

> On Jul 24, 2019, at 1:23 PM, Justin Pothoof  wrote:
> 
> Thank you Jon,
> 
> I will try writing it in one equation as you suggested.  Regarding the 
> experimental data, I have an initial potential curve described by a sum of 
> sines fit as well as initial positive/negative charge density curves 
> described by a specific equation I'll show in a file.
> 
> Thanks for the help!
> Justin
> 
> On Wed, Jul 24, 2019 at 6:06 AM Guyer, Jonathan E. Dr. (Fed) via fipy 
>  wrote:
> Justin -
> 
> What that error means is that if you write 'var=' for any Term, then you must 
> write 'var=' for every Term.
> 
> In your equations:
> 
> ```
> Pion.equation = TransientTerm() + k_rec * Pion * Nion + 
> ConvectionTerm(coeff=1 / q, var=Jp) == 0
> Nion.equation = TransientTerm() + k_rec * Pion * Nion + 
> ConvectionTerm(coeff=-1 / q, var=Jn) == 0
> potential.equation = DiffusionTerm(1 / q * epsilon) + Pion * Nion == 0
> Jp.equation = ImplicitSourceTerm() + ConvectionTerm(coeff=-q * mu_p * Pion, 
> var=potential) + ConvectionTerm(coeff=-q * Dp, var=Pion) == 0
> Jn.equation = ImplicitSourceTerm() + ConvectionTerm(coeff=-q * mu_n * Nion, 
> var=potential) + ConvectionTerm(coeff=q * Dn, var=Nion) == 0
> ```
> FiPy does not know what Variable TransientTerm() applies to in Pion.equation 
> and Nion.equation, DiffusionTerm() in potential.equation, nor 
> ImplicitSourceTerm() in Jp.equation and Jn.equation.
> 
> As a further point, you should not solve Pion.equation and Jp.equation 
> separately nor Nion.equation/Jn.equation. Combine them for a single, second 
> order PDE each for n and for p. You will want to take care that, e.g., the 
> equation should not be taking the gradient (\nabla) of a vector (Jn), which 
> would give you a tensor; rather, the expression should be divergence 
> (\nabla\cdot) of a vector (Jn), giving a scalar.
> 
> As to comparing to your experimental data, I'd need to know what form it 
> takes to advise further.
> 
> - Jon
> 
> > On Jul 23, 2019, at 9:09 PM, Justin Pothoof  wrote:
> > 
> > Hello,
> > 
> > I understand that modeling the drift diffusion equations are very 
> > challenging, but I'm having issues actually writing the equations.  I keep 
> > encountering the error: "fipy.terms.ExplicitVariableError: Terms with 
> > explicit Variables cannot mix with Terms with implicit Variables."
> > 
> > Additionally, I have fitted experimental data that describes what the 
> > initial conditions for my system should be, but I don't know how to include 
> > that into FiPy.  I would appreciate any guidance that you can offer.  I 
> > will include a pdf of what the equations I'm trying to write are as well as 
> > the file I have written thus far. 
> > 
> > Thank you,
> > Justin
> >  > Testing.py>___
> > 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 ]
> 


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

Re: Drift Diffusion Equation Setup

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Justin -

What that error means is that if you write 'var=' for any Term, then you must 
write 'var=' for every Term.

In your equations:

```
Pion.equation = TransientTerm() + k_rec * Pion * Nion + ConvectionTerm(coeff=1 
/ q, var=Jp) == 0
Nion.equation = TransientTerm() + k_rec * Pion * Nion + ConvectionTerm(coeff=-1 
/ q, var=Jn) == 0
potential.equation = DiffusionTerm(1 / q * epsilon) + Pion * Nion == 0
Jp.equation = ImplicitSourceTerm() + ConvectionTerm(coeff=-q * mu_p * Pion, 
var=potential) + ConvectionTerm(coeff=-q * Dp, var=Pion) == 0
Jn.equation = ImplicitSourceTerm() + ConvectionTerm(coeff=-q * mu_n * Nion, 
var=potential) + ConvectionTerm(coeff=q * Dn, var=Nion) == 0
```
FiPy does not know what Variable TransientTerm() applies to in Pion.equation 
and Nion.equation, DiffusionTerm() in potential.equation, nor 
ImplicitSourceTerm() in Jp.equation and Jn.equation.

As a further point, you should not solve Pion.equation and Jp.equation 
separately nor Nion.equation/Jn.equation. Combine them for a single, second 
order PDE each for n and for p. You will want to take care that, e.g., the 
equation should not be taking the gradient (\nabla) of a vector (Jn), which 
would give you a tensor; rather, the expression should be divergence 
(\nabla\cdot) of a vector (Jn), giving a scalar.

As to comparing to your experimental data, I'd need to know what form it takes 
to advise further.

- Jon

> On Jul 23, 2019, at 9:09 PM, Justin Pothoof  wrote:
> 
> Hello,
> 
> I understand that modeling the drift diffusion equations are very 
> challenging, but I'm having issues actually writing the equations.  I keep 
> encountering the error: "fipy.terms.ExplicitVariableError: Terms with 
> explicit Variables cannot mix with Terms with implicit Variables."
> 
> Additionally, I have fitted experimental data that describes what the initial 
> conditions for my system should be, but I don't know how to include that into 
> FiPy.  I would appreciate any guidance that you can offer.  I will include a 
> pdf of what the equations I'm trying to write are as well as the file I have 
> written thus far. 
> 
> Thank you,
> Justin
>  Testing.py>___
> 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 ]

ANN: FiPy 3.3

[Guyer, Jonathan E. Dr. (Fed) via fipy]

We are pleased to announce the release of FiPy 3.3.

http://www.ctcms.nist.gov/fipy

This release brings support for Python 2 and Python 3 from the same source, 
without any 2to3 translation.  Thanks to @pya and @woodscn for getting things 
started.

This transition secures FiPy for the scheduled [drop of support for Python 2.7 
on January
1, 2020](https://www.python.org/dev/peps/pep-0373/#update).  Be aware that 
performance suffers substantially under Py3k, as neither Pysparse (fast serial) 
nor PyTrilinos (parallel) is available for Py3k. As a result, our next priority 
will be to add support for petsc4py solvers.

Note that, with this release, we are dropping the `develop` branch, adopting 
more of a [GitHub flow](https://guides.github.com/introduction/flow/) 
development model. If you track our repository on GitHub, please switch to 
`master`. As a convenience, we will endeavor to keep `develop` up-to-date with 
`master` in the short term, but we will be deleting the `develop` branch in the 
not-too-distant future.

Pulls
-

- Automate spell check (#657)
- Fix gmsh on windows (#648)
- Fix sphinx documentation (#647)
- Migrate to Py3k (#645)
- `gmshMesh.py` compatibility with Gmsh > 3.0.6 (#644)
  Thanks to @xfong.

Fixes
-

- #655: When Python 2 and 3 are installed, Mayavi wont work.
  Thanks to @Hendrik410.
- #646: Deprecate develop branch
- #643: Automate release process
- #601: `contents.rst` and `manual.rst` are a recursive mess
- #597: Use GitHub link for the compressed archive in documentation
- #557: `faceGradAverage` is stupid
- #552: documentation integration
- #458: Documentation wrong for precedence of `Lx` and `dx` for
  `NonUniformGrids`
- #457: Special methods are not included in Sphinx documentation
- #432: Python 3 issues
- #340: Don't upload packages to PyPi, just add the master url



FiPy is an object oriented, partial differential equation (PDE) solver,
written in Python, based on a standard finite volume (FV) approach. The
framework has been developed in the Metallurgy Division and Center for
Theoretical and Computational Materials Science (CTCMS), in the Material
Measurement Laboratory (MML) at the National Institute of Standards and
Technology (NIST).

The solution of coupled sets of PDEs is ubiquitous to the numerical
simulation of science problems. Numerous PDE solvers exist, using a variety
of languages and numerical approaches. Many are proprietary, expensive and
difficult to customize. As a result, scientists spend considerable
resources repeatedly developing limited tools for specific problems. Our
approach, combining the FV method and Python, provides a tool that is
extensible, powerful and freely available. A significant advantage to
Python is the existing suite of tools for array calculations, sparse
matrices and data rendering.

The FiPy framework includes terms for transient diffusion, convection and
standard sources, enabling the solution of arbitrary combinations of
coupled elliptic, hyperbolic and parabolic PDEs. Currently implemented
models include phase field treatments of polycrystalline, dendritic, and
electrochemical phase transformations as well as a level set treatment of
the electrodeposition process.


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

Re: ternary electrolyte

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Scott -

I have a better understanding now, and the fact that you're using python 3.7 
was helpful to know. I couldn't reproduce your binary notebook because I was 
running python 2.7 your declaration of z1 and z2 as integers resulted in 
integer division in the declaration of C2, giving C2 = 0, which was why I was 
getting singular matrix errors.

Changing z1 and z2 to floats (or running under python 3.7) recovered the 
agreement with the analytical result that you found. To be honest, I don't 
really know why it works. It looks to me like a fortuitous combination of the 
default no-flux condition on phi (*not* on C2) and the fact that C2.faceGrad = 
0 on the left, giving rise to a strong sink in phi at that boundary, resulted 
in the desired solution for phi and therefore in C1 and C2.

As you've found, this doesn't work so neatly in the ternary case. The best I 
can offer is in these notebooks

https://gist.github.com/guyer/043943d7d00cd57bd90fec7407f88a37

where I have explicitly used the no-flux conditions at the left boundary to 
obtain appropriate constraints on phi.faceGrad (and C2.faceGrad for the 
ternary). With these changes, the agreement with the analytical results on West 
seems good. I don't see any likely way that this could be automated.

- Jon

> On Jun 14, 2019, at 5:06 PM, Scott Calabrese Barton  wrote:
> 
> In order to explain the physical reasoning, consider the binary case, in 
> which say, copper is deposited at a surface from copper sulfate. The copper 
> is transported to the surface to be deposited, but there can be no transport 
> of sulfate, because it has nowhere to go.  Electroneutrality requires that 
> the concentration profiles be identical, and so in order for the flux of 
> sulfate to be zero, the system must create a potential gradient such that 
> migration of sulfate counters diffusion of sulfate.  This gradient 
> consequently *increases* the flux of copper to the surface as compared to 
> diffusion alone. This is a well-established analysis, and the same logic 
> extends to the ternary system where both non-depositing ions have zero flux.
> 
> Regarding the environment, I’m using python 3.7, fipy 3.2 converted using 
> 2to3, and numpy 1.6.3. I apologize that this is taking up a lot of your time.
> 
> ☘
> 
> 
>> On Jun 14, 2019, at 3:39 PM, Guyer, Jonathan E. Dr. (Fed) via fipy 
>>  wrote:
>> 
>> 1. As before, there is no flux condition on species 3
>> 
>> 2. Unless your transport is at the speed of light, nonzero flux will not 
>> alter Poisson's equation. That's probably a red herring, though, for now. 
>> 
>> More germane, the notebook at 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__bit.ly_2wOzxfK=DwIGaQ=nE__W8dFE-shTxStwXtp0A=GFdsMpHIw-aduHn9jOIpyQ=0CNSsyiu_ttXhR5iC0w5LMRTk_0q8p-rHKbrWl-b9JI=BrL8P9a6glMNFn_mt5Y-XM5RutSOJZ9lSwj6ETM0FDM=
>>   does not solve for me, with a singular matrix error. Replacing 
>> C2.faceGrad.divergence with DiffusionTerm(coeff=-z1/z2, var=C1) gives a 
>> converged solution, but again, Phi = 0. Phi = 0, C1 = C2, with grad(C1) = 
>> grad(C2) = const is a solution to this set of equations. I still see nothing 
>> in the conditions you have provided that would induce Phi to curve. 
>> 
>> I have tried both SciPy and Pysparse and I don't get the results you show 
>> for the binary. Can you specify what environment you're running on?
>> 
>>> On Jun 14, 2019, at 1:32 PM, Scott Calabrese Barton  wrote:
>>> 
>>> Hi, two answers:
>>> 
>>> 1. Phi=0 is not a solution because it does not satisfy the flux condition 
>>> on species 3.
>>> 
>>> 2. If nonuniform charge or nonuniform permittivity are my only two choices, 
>>> I’d go with nonuniform permittivity, due to varying concentrations. 
>>> However, this is non-equilibrium system so I would suggest that nonzero 
>>> flux can also give rise to potential gradients. This may be more clear in 
>>> the binary system 
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__bit.ly_2wOzxfK=DwIGaQ=nE__W8dFE-shTxStwXtp0A=GFdsMpHIw-aduHn9jOIpyQ=0CNSsyiu_ttXhR5iC0w5LMRTk_0q8p-rHKbrWl-b9JI=BrL8P9a6glMNFn_mt5Y-XM5RutSOJZ9lSwj6ETM0FDM=
>>>  .
>>> 
>>> A physical manifestation of this system is copper deposition across a 
>>> boundary layer, say from copper sulfate with a supporting electrolyte such 
>>> as sulfuric acid. In this case the three species might be copper, protons, 
>>> and sulfate ions.
>>> 
>>> ☘
>>> 
>>>> On Jun 14, 2019, at 11:26 AM, Guyer, Jonathan E. Dr. (Fed) via fipy 
>>>>  wrote:
>>>> 
>>>> Phi = 0 is a solution. Are you suggesting that this set of equations has 
>>

Re: ternary electrolyte

[Guyer, Jonathan E. Dr. (Fed) via fipy]

1. As before, there is no flux condition on species 3

2. Unless your transport is at the speed of light, nonzero flux will not alter 
Poisson's equation. That's probably a red herring, though, for now. 

More germane, the notebook at http://bit.ly/2wOzxfK does not solve for me, with 
a singular matrix error. Replacing C2.faceGrad.divergence with 
DiffusionTerm(coeff=-z1/z2, var=C1) gives a converged solution, but again, Phi 
= 0. Phi = 0, C1 = C2, with grad(C1) = grad(C2) = const is a solution to this 
set of equations. I still see nothing in the conditions you have provided that 
would induce Phi to curve. 

I have tried both SciPy and Pysparse and I don't get the results you show for 
the binary. Can you specify what environment you're running on?

> On Jun 14, 2019, at 1:32 PM, Scott Calabrese Barton  wrote:
> 
> Hi, two answers:
> 
> 1. Phi=0 is not a solution because it does not satisfy the flux condition on 
> species 3.
> 
> 2. If nonuniform charge or nonuniform permittivity are my only two choices, 
> I’d go with nonuniform permittivity, due to varying concentrations. However, 
> this is non-equilibrium system so I would suggest that nonzero flux can also 
> give rise to potential gradients. This may be more clear in the binary system 
> http://bit.ly/2wOzxfK.
> 
> A physical manifestation of this system is copper deposition across a 
> boundary layer, say from copper sulfate with a supporting electrolyte such as 
> sulfuric acid. In this case the three species might be copper, protons, and 
> sulfate ions.
> 
> ☘
> 
>> On Jun 14, 2019, at 11:26 AM, Guyer, Jonathan E. Dr. (Fed) via fipy 
>>  wrote:
>> 
>> Phi = 0 is a solution. Are you suggesting that this set of equations has 
>> more than one solution?
>> 
>> I realize you are not solving Poisson's equation. My question was to 
>> consider the broader physics of the problem. Physically, non-uniform 
>> electric field means either that charge is non-uniform, which is not in your 
>> problem, or permittivity is non-uniform, which is not in your problem. So, 
>> what's in your problem that resolves that physical inconsistency?. 
>> 
>>> On Jun 14, 2019, at 10:53 AM, Scott Calabrese Barton  wrote:
>>> 
>>> To answer your questions first, the non-zero gradient in Phi counteracts 
>>> the gradients in C2 and C3 such that the migration and diffusion flux 
>>> cancel and overall flux is zero for those species. Regarding the curvature, 
>>> you’re thinking of the Poisson equation that is only valid in this context 
>>> when concentrations are constant.  The variations in concentration give 
>>> rise to nonlinear variations in Phi.
>>> 
>>> Perhaps I should point out that we can get the numerical solution using 
>>> other solvers such as solve_bvp from scipy, and an analytical solution is 
>>> also available (that’s the source of the plot). So the problem is well 
>>> defined. I’ll be happy to share those calculations if needed. I’m using 
>>> this problem as an example to learn more about fipy.
>>> 
>>>> On Jun 14, 2019, at 9:10 AM, Guyer, Jonathan E. Dr. (Fed) via fipy 
>>>>  wrote:
>>>> 
>>>> I had the same initial thought, but you're not adding new information by 
>>>> doing that. You can see this by looking at the matrix stencil that results 
>>>> from these equations:
>>>> 
>>>> X  X C1
>>>> X   C2
>>>> XX C3  = 0
>>>> XXX  Phi
>>>> 
>>>> That bottom right sector of the matrix is empty and so the matrix solvers 
>>>> cannot find a solution because you're now trying to solve for four 
>>>> unknowns with what are really only three equations.
>>>> 
>>>> Things to consider:
>>>> 
>>>> In the solution you posted from West, Phi does not have zero gradient at 
>>>> either end of the domain. Why? What boundary condition is driving that?
>>>> 
>>>> Phi is curved, which implies that there is net charge in the system, but 
>>>> you assert zero charge throughout. How does West reconcile that 
>>>> inconsistency?
>>>> 
>>>>> On Jun 13, 2019, at 11:25 AM, Scott Calabrese Barton  wrote:
>>>>> 
>>>>> That’s true, so we can make C3 explicit (full code at 
>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__bit.ly_2F7UQgR-3D=DwIGaQ=nE__W8dFE-shTxStwXtp0A=GFdsMpHIw-aduHn9jOIpyQ=NXf47PawWEovDQCuiqrE25DZuppCDLEVN9L9lPfcl3c=3mcnknSVK1Ij82U2PK6itcevIOeNgXVMqLhUYYihMqc=
>>>>>   ):
>>>>> 
>>>>> # Variables

Re: ternary electrolyte

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Phi = 0 is a solution. Are you suggesting that this set of equations has more 
than one solution?

I realize you are not solving Poisson's equation. My question was to consider 
the broader physics of the problem. Physically, non-uniform electric field 
means either that charge is non-uniform, which is not in your problem, or 
permittivity is non-uniform, which is not in your problem. So, what's in your 
problem that resolves that physical inconsistency?. 

> On Jun 14, 2019, at 10:53 AM, Scott Calabrese Barton  wrote:
> 
> To answer your questions first, the non-zero gradient in Phi counteracts the 
> gradients in C2 and C3 such that the migration and diffusion flux cancel and 
> overall flux is zero for those species. Regarding the curvature, you’re 
> thinking of the Poisson equation that is only valid in this context when 
> concentrations are constant.  The variations in concentration give rise to 
> nonlinear variations in Phi.
> 
> Perhaps I should point out that we can get the numerical solution using other 
> solvers such as solve_bvp from scipy, and an analytical solution is also 
> available (that’s the source of the plot). So the problem is well defined. 
> I’ll be happy to share those calculations if needed. I’m using this problem 
> as an example to learn more about fipy.
> 
>> On Jun 14, 2019, at 9:10 AM, Guyer, Jonathan E. Dr. (Fed) via fipy 
>>  wrote:
>> 
>> I had the same initial thought, but you're not adding new information by 
>> doing that. You can see this by looking at the matrix stencil that results 
>> from these equations:
>> 
>> X  X C1
>> X   C2
>> XX C3  = 0
>> XXX  Phi
>> 
>> That bottom right sector of the matrix is empty and so the matrix solvers 
>> cannot find a solution because you're now trying to solve for four unknowns 
>> with what are really only three equations.
>> 
>> Things to consider:
>> 
>> In the solution you posted from West, Phi does not have zero gradient at 
>> either end of the domain. Why? What boundary condition is driving that?
>> 
>> Phi is curved, which implies that there is net charge in the system, but you 
>> assert zero charge throughout. How does West reconcile that inconsistency?
>> 
>>> On Jun 13, 2019, at 11:25 AM, Scott Calabrese Barton  wrote:
>>> 
>>> That’s true, so we can make C3 explicit (full code at 
>>> http://bit.ly/2F7UQgR= ):
>>> 
>>> # Variables
>>> C1= CellVariable(mesh = mesh, value = 1.0)
>>> C2= CellVariable(mesh = mesh, value = 4.0/3.0)
>>> Phi = CellVariable(mesh = mesh, value = 0)
>>> 
>>> C30 = -1/z3 * (z1*1.0 + z2*C20)   # Electroneutrality
>>> C3= CellVariable(mesh = mesh, value = C30)
>>> 
>>> # Boundary Conditions
>>> C1.constrain(1.0, mesh.facesRight)
>>> C2.constrain(C20, mesh.facesRight)
>>> C3.constrain(C30, mesh.facesRight)
>>> Phi.constrain(-0.2, mesh.facesRight)
>>> C1.constrain(0.0, mesh.facesLeft)
>>> 
>>> # Governing Equations
>>> Eq1 = + DiffusionTerm(coeff=z1*C1, var=Phi) + DiffusionTerm(coeff=1.0, 
>>> var=C1)
>>> Eq2 = + DiffusionTerm(coeff=z2*C2, var=Phi) + DiffusionTerm(coeff=1.0, 
>>> var=C2)
>>> Eq3 = + DiffusionTerm(coeff=z3*C3, var=Phi) + DiffusionTerm(coeff=1.0, 
>>> var=C3)
>>> 
>>> Eq4 = ImplicitSourceTerm(coeff=z1, var=C1) + \
>>>ImplicitSourceTerm(coeff=z2, var=C2) + \
>>>ImplicitSourceTerm(coeff=z3, var=C3)
>>> 
>>> Eqns = Eq1 & Eq2 & Eq3 & Eq4
>>> 
>>> 
>>> However, this set of equations does not converge. I’m fairly certain that I 
>>> am mismanaging the boundary conditions.
>>> 
>>> 
>>>> On Jun 12, 2019, at 5:02 PM, Guyer, Jonathan E. Dr. (Fed) via fipy 
>>>>  wrote:
>>>> 
>>>> There's no zero-flux BC on C3 because there's no such thing as C3 as far 
>>>> as FiPy is concerned. The boundary conditions on C3 are entirely 
>>>> determined by the boundary conditions on C1 and C2 (Dirichlet on the right 
>>>> and Robin on the left). The solution obtained satisfies the equations and 
>>>> boundary conditions given to FiPy. 
>>>> 
>>>>> On Jun 12, 2019, at 2:19 PM, Scott Calabrese Barton  wrote:
>>>>> 
>>>>> Jon, thanks for catching that typo.  I wish it were the problem!
>>>>> 
>>>>> The solution with grad phi=0 does not satisfy the zero-flux boundary 
>>>>> condition on species 3.  In the absence of a potential gradient, that 
>>>>

Re: ternary electrolyte

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Scott -

Eq2 appears to have a typo:

-Eq2 = DiffusionTerm(coeff=z2*C1, var=Phi) + DiffusionTerm(coeff=1.0, var=C2)
+Eq2 = DiffusionTerm(coeff=z2*C2, var=Phi) + DiffusionTerm(coeff=1.0, var=C2)

Eq3 has (much) better coupling if written like this:

-Eq3 = DiffusionTerm(coeff=z3*C3, var=Phi) + (C3.faceGrad).divergence 
+Eq3 = DiffusionTerm(coeff=z3*C3, var=Phi) - DiffusionTerm(coeff=-z1/z3, 
var=C1) - DiffusionTerm(coeff=-z2/z3, var=C2)

[Note that this way you don't need to evaluate .faceGrad at the boundaries, so 
your issue #650 doesn't come up. We don't upwind at the boundaries because it's 
complicated and expensive to do right and it's unusual to care.]

With these changes, the solution converges in one sweep, but does not agree 
with the Analytical Solution you give from West. 

I don't understand a couple of things though. As posed, what governs \Phi? I 
get \Phi = 0 and see no reason why it would be otherwise. Typically, I would 
expect Poisson's equation to be obeyed. Since you assert charge 
electroneutrality, this reduces to Laplace's equation, but in that case, the 
slope of \Phi should be constant (unless the permittivity is non-uniform, but 
you don't have a permittivity). In the Analytical plot, \Phi has definite 
curvature.

My guess is you don't need Eq3 (it'll get taken care of automatically) and you 
need some form of Poisson's equation.

- Jon

> On Jun 11, 2019, at 4:48 PM, Scott Calabrese Barton  wrote:
> 
> I’ve had some trouble using fipy for the 1D, steady-state ternary electrolyte 
> problem, which involves coupled, nonlinear migration and diffusion.
> 
> A text version of the model is listed below.  A more complete development is 
> at 
> https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbit.ly%2F2wJDXobdata=02%7C01%7Cjonathan.guyer%40nist.gov%7C1687dc7e080545a63f0708d6eeae58e7%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636958829930551626sdata=cSBGKKJG0%2Ft%2FMtTZbnTwenKAVsKPHa%2F1C8NgupkRI0E%3Dreserved=0
> 
> from fipy import *
> 
> # Parameters
> nx=50
> C20=4.0/3.0
> z1, z2, z3= 2.0, -2.0, 1.0
> 
> # Mesh
> mesh = Grid1D(nx=nx, dx=1.0/nx)
> 
> # Variables
> C1= CellVariable(mesh = mesh, value = 1.0)
> C2= CellVariable(mesh = mesh, value = 4.0/3.0)
> Phi = CellVariable(mesh = mesh, value = -0.5)
> 
> # Electroneutrality
> C3 = -1/z3 * (z1*C1 + z2*C2)
> 
> # Boundary Conditions
> C1.constrain(1.0, mesh.facesRight)
> C1.constrain(0.0, mesh.facesLeft)
> C2.constrain(C20, mesh.facesRight)
> Phi.constrain(0, mesh.facesRight)
> 
> # Governing Equations
> Eq1 = DiffusionTerm(coeff=z1*C1, var=Phi) + DiffusionTerm(coeff=1.0, var=C1)
> Eq2 = DiffusionTerm(coeff=z2*C1, var=Phi) + DiffusionTerm(coeff=1.0, var=C2)
> Eq3 = DiffusionTerm(coeff=z3*C3, var=Phi) + (C3.faceGrad).divergence 
> 
> Eqns = Eq1 & Eq2 & Eq3
> 
> # Solution
> res = 1e+10
> restol= 1e-3
> 
> while res > restol:
>res = Eqns.sweep()
>print(res)
> 
> 
> However, this system does not converge. I suspect the issue is with boundary 
> conditions. I’ve tried zeroing out the diffusion coefficients at the 
> boundary, but that does not seem to make a difference here. I am able to use 
> this approach for the analogous binary problem: 
> https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbit.ly%2F2wOzxfKdata=02%7C01%7Cjonathan.guyer%40nist.gov%7C1687dc7e080545a63f0708d6eeae58e7%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636958829930551626sdata=CkRvDWJQl%2FjHRTwtxd6y1Krs3VuALc2bAOXKJYsdmEk%3Dreserved=0
> 
> Any insights or suggestions would be welcome.
> 
> Cheers,
> Scott☘
> 
> 
> ___
> 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 ]

ANN: FiPy 3.2

[Guyer, Jonathan E. Dr. (Fed) via fipy]

We are pleased to announce the release of FiPy 3.2.

 http://www.ctcms.nist.gov/fipy

This is predominantly a DevOps release.  The focus has been on making
FiPy easier to install with conda.  It's also possible to install a
minimal set of prerequisites with pip.  Further, FiPy is
automatically tested on all major platforms using cloud-based
Continuous Integration (linux with CircleCI, macOS with TravisCI, 
and Windows with AppVeyor).

This release addresses 38 issues.



FiPy is an object oriented, partial differential equation (PDE) solver,
written in Python, based on a standard finite volume (FV) approach. The
framework has been developed in the Metallurgy Division and Center for
Theoretical and Computational Materials Science (CTCMS), in the Material
Measurement Laboratory (MML) at the National Institute of Standards and
Technology (NIST).

The solution of coupled sets of PDEs is ubiquitous to the numerical
simulation of science problems. Numerous PDE solvers exist, using a variety
of languages and numerical approaches. Many are proprietary, expensive and
difficult to customize. As a result, scientists spend considerable
resources repeatedly developing limited tools for specific problems. Our
approach, combining the FV method and Python, provides a tool that is
extensible, powerful and freely available. A significant advantage to
Python is the existing suite of tools for array calculations, sparse
matrices and data rendering.

The FiPy framework includes terms for transient diffusion, convection and
standard sources, enabling the solution of arbitrary combinations of
coupled elliptic, hyperbolic and parabolic PDEs. Currently implemented
models include phase field treatments of polycrystalline, dendritic, and
electrochemical phase transformations as well as a level set treatment of
the electrodeposition process.

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

Re: 1D diffusion problem

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Also, the natural boundary condition for FiPy is no-flux, so there's no need to 
do

  T_var.faceGrad.constrain(0, where=mesh.facesLeft)

> On Apr 22, 2019, at 1:28 PM, Guyer, Jonathan E. Dr. (Fed) via fipy 
>  wrote:
> 
> Clara -
> 
> - The cause of everything dropping to zero is that T_var.old is initialized 
> to zero. This isn't a particularly useful initial value, but that's what it 
> is. Usually, T_var.updateOld() is the first thing called in the time step 
> loop, so this initial condition doesn't matter, but because of the way you've 
> structured your adaptive time steps, the first sweep is done with an 
> erroneous initial condition.
> 
> Call T_var.updateOld() one time before you start taking time steps.
> 
> - Your sweep tolerance is too severe. I adjusted to 1.0e-6 and the adaptive 
> stepper works much better.
> 
> - The way you define and update dt, you'll get recursion errors eventually. 
> Instead, define
> 
>   dt = 0.9*dr**2/(2.0*Diff[0].value)
> 
>   If you're curious, this is because:
> 
>   * Diff is a FaceVariable
>   * so, Diff[0] is a UnaryOperator Variable
>   * so, dt = 0.9*dr**2/(2.0*Diff[0]) is a BinaryOperator Variable
>   * so, dt *= 1.1/dt *= 0.8 is a BinaryOperator Variable that gets nested 
> deeper 
> and deeper every time step
> 
>   Diff[0].value short circuits that
> 
> - Your problem is completely linear, so sweeps aren't necessary at this point
> 
> - This equation is fully implicit, so there's no need to start with such a 
> tiny initial time step
> 
> - Jon
> 
>> On Apr 19, 2019, at 2:42 PM, Clara Maurel  wrote:
>> 
>> Hello everyone,
>> 
>> I apologize in advance for this very basic question…
>> I am trying to solve a 1D diffusion problem where I have a cooling planet 
>> (core+mantle) with an initial temperature profile and a diffusion 
>> coefficient that takes different values in the core and in the mantle. I 
>> want a fixed boundary condition at the surface (T = 200 K) and a zero 
>> gradient at the center of the body, but the temperature at the center (left 
>> of the mesh) is not fixed and should cool.
>> When I run the script, the whole profile immediately goes down to zero 
>> (except the end right of the mesh) and diffuses from there. I must be doing 
>> something wrong with the left boundary condition but I can’t figure out what.
>> 
>> Could someone help me to find out what I missed? Any hint would be greatly 
>> appreciated!
>> 
>> Thank you in advance for your help!
>> Clara
>> 
>> Here is my simple script:
>> 
>> from datetime import datetime
>> startTime = datetime.now()
>> import numpy as np
>> import scipy
>> from fipy import *
>> from fipy.solvers.pysparse import LinearLUSolver as Solver
>> from sympy import *
>> from scipy import interpolate
>> 
>> def Get_closest_id(L,value):
>>return list(L).index(min(L, key=lambda x:abs(x-value)))
>> 
>> ##
>> # DIFFUSION EQUATION: INITIALIZATION #
>> ##
>> 
>> ## Dimensions (km)
>> R_body = 200.0
>> R_core = 50.0
>> 
>> ## Temperatures (K)
>> T_core = 1200.0
>> T_surf = 200.0
>> 
>> ## Mesh
>> nr = 1000
>> dr = R_body / nr
>> mesh = Grid1D(nx=nr, dx=dr)
>> 
>> ## Variable
>> T_var = CellVariable(name="T", mesh=mesh, hasOld=True)
>> 
>> ## Initial temperature profile
>> slope = (T_core-T_surf)/(R_core-R_body)
>> intercept = T_core-slope*R_core
>> T_var[:] = np.array([T_core]*int(R_core/dr) + 
>> list(slope*np.arange(R_core+dr, R_body+dr, dr)+intercept))
>> 
>> ## Initial conditions (fixed surface value, null gradient at the center of 
>> the core)
>> T_var.constrain(T_surf, mesh.facesRight)
>> T_var.faceGrad.constrain(0, where=mesh.facesLeft)
>> 
>> ## Diffusion coefficient (different in core and mantle, in km2 My-1)
>> Diff = FaceVariable(mesh=mesh)
>> X = mesh.faceCenters[0]
>> Diff.setValue(150.0, where=(R_core >= X))
>> Diff.setValue(15.0, where=(R_core < X) & (R_body >= X))
>> 
>> ## Equation
>> eq = TransientTerm(coeff=1.) == DiffusionTerm(Diff)
>> 
>> if __name__ == "__main__":
>>viewer = Viewer(vars=(T_var),ymin=0,ymax=1400)
>>viewer.plot()
>> 
>> if __name__ == '__main__':
>>raw_input("Press  to proceed...")
>> 
>> ## Time and integration parameters (time in My; 3.154e13 = 1 My in s)
>> time = 0.0
>> duration = 1000.0
>> dt = 0.9*dr**2/(2.0

Re: 1D diffusion problem

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Clara -

- The cause of everything dropping to zero is that T_var.old is initialized to 
zero. This isn't a particularly useful initial value, but that's what it is. 
Usually, T_var.updateOld() is the first thing called in the time step loop, so 
this initial condition doesn't matter, but because of the way you've structured 
your adaptive time steps, the first sweep is done with an erroneous initial 
condition.

Call T_var.updateOld() one time before you start taking time steps.

- Your sweep tolerance is too severe. I adjusted to 1.0e-6 and the adaptive 
stepper works much better.

- The way you define and update dt, you'll get recursion errors eventually. 
Instead, define

   dt = 0.9*dr**2/(2.0*Diff[0].value)

   If you're curious, this is because:

   * Diff is a FaceVariable
   * so, Diff[0] is a UnaryOperator Variable
   * so, dt = 0.9*dr**2/(2.0*Diff[0]) is a BinaryOperator Variable
   * so, dt *= 1.1/dt *= 0.8 is a BinaryOperator Variable that gets nested 
deeper 
 and deeper every time step

   Diff[0].value short circuits that

- Your problem is completely linear, so sweeps aren't necessary at this point

- This equation is fully implicit, so there's no need to start with such a tiny 
initial time step

- Jon

> On Apr 19, 2019, at 2:42 PM, Clara Maurel  wrote:
> 
> Hello everyone,
> 
> I apologize in advance for this very basic question…
> I am trying to solve a 1D diffusion problem where I have a cooling planet 
> (core+mantle) with an initial temperature profile and a diffusion coefficient 
> that takes different values in the core and in the mantle. I want a fixed 
> boundary condition at the surface (T = 200 K) and a zero gradient at the 
> center of the body, but the temperature at the center (left of the mesh) is 
> not fixed and should cool.
> When I run the script, the whole profile immediately goes down to zero 
> (except the end right of the mesh) and diffuses from there. I must be doing 
> something wrong with the left boundary condition but I can’t figure out what.
> 
> Could someone help me to find out what I missed? Any hint would be greatly 
> appreciated!
> 
> Thank you in advance for your help!
> Clara
> 
> Here is my simple script:
> 
> from datetime import datetime
> startTime = datetime.now()
> import numpy as np
> import scipy
> from fipy import *
> from fipy.solvers.pysparse import LinearLUSolver as Solver
> from sympy import *
> from scipy import interpolate
> 
> def Get_closest_id(L,value):
> return list(L).index(min(L, key=lambda x:abs(x-value)))
> 
> ##
> # DIFFUSION EQUATION: INITIALIZATION #
> ##
> 
> ## Dimensions (km)
> R_body = 200.0
> R_core = 50.0
> 
> ## Temperatures (K)
> T_core = 1200.0
> T_surf = 200.0
> 
> ## Mesh
> nr = 1000
> dr = R_body / nr
> mesh = Grid1D(nx=nr, dx=dr)
> 
> ## Variable
> T_var = CellVariable(name="T", mesh=mesh, hasOld=True)
> 
> ## Initial temperature profile
> slope = (T_core-T_surf)/(R_core-R_body)
> intercept = T_core-slope*R_core
> T_var[:] = np.array([T_core]*int(R_core/dr) + list(slope*np.arange(R_core+dr, 
> R_body+dr, dr)+intercept))
> 
> ## Initial conditions (fixed surface value, null gradient at the center of 
> the core)
> T_var.constrain(T_surf, mesh.facesRight)
> T_var.faceGrad.constrain(0, where=mesh.facesLeft)
> 
> ## Diffusion coefficient (different in core and mantle, in km2 My-1)
> Diff = FaceVariable(mesh=mesh)
> X = mesh.faceCenters[0]
> Diff.setValue(150.0, where=(R_core >= X))
> Diff.setValue(15.0, where=(R_core < X) & (R_body >= X))
> 
> ## Equation
> eq = TransientTerm(coeff=1.) == DiffusionTerm(Diff)
> 
> if __name__ == "__main__":
> viewer = Viewer(vars=(T_var),ymin=0,ymax=1400)
> viewer.plot()
> 
> if __name__ == '__main__':
> raw_input("Press  to proceed...")
> 
> ## Time and integration parameters (time in My; 3.154e13 = 1 My in s)
> time = 0.0
> duration = 1000.0
> dt = 0.9*dr**2/(2.0*Diff[0])
> 
> total_sweeps = 4
> tolerance = 1.0e-10
> 
> solver = Solver()
> 
> #---#
> # DIFFUSION EQUATION: MAIN LOOP #
> #---#
> 
> while time < duration:
> 
> res0 = eq.sweep(T_var, dt=dt, solver=solver)
> 
> for sweeps in range(total_sweeps):
> res = eq.sweep(T_var, dt=dt, solver=solver)
> 
> if res < res0 * tolerance:
> time += dt
> dt *= 1.1
> T_var.updateOld()
> print dt, res
> if __name__ == '__main__':
> viewer.plot()
> 
> else:
> dt *= 0.8
> T_var[:] = T_var.old
> print "warning " + str(res)
> 
> print datetime.now() - startTime
> 
> if __name__ == '__main__':
> raw_input("Press  to proceed...")
> 
> 
> ___
> 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

Re: Question regarding Boundary Condition Implementation

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Daniel -

Two things going on here:

- Your constraint is being applied at the tip of the wedge of the cylindrical 
coordinates. Since this "face" has no area, that Dirichlet condition doesn't 
generate any flux in or out of the domain. Offsetting the cylinder slightly 
from the origin resolves this:

mesh = CylindricalGrid1D(Lr = L,nr=nx) + [[L/nx]]

I recommend giving some thought as to whether it even makes sense to apply a 
Dirichlet condition along the centerline of a cylinder.

- Because you've introduced coefficients which change with temperature, your 
equation is now nonlinear and so sweeping is required (2 is apparently enough). 
At each time step, execute:

for sweep in range(2):
res = eq.sweep(dt=dt)

rho.setValue(rho_l,where = PCM & (T>350) )
k.setValue(k_l,where = PCM & (T>350))
Cp.setValue(Cp_l,where = PCM & (T>350))

With these changes, the evolution seems generally similar to your Grid1D case.

- Jon

> On Apr 15, 2019, at 1:28 PM, Daniel DeSantis  wrote:
> 
> Jonathan,
> 
> I have just a few follow up questions. Namely, regarding to working within 
> cylindrical coordinates. If I switch the mesh to cylindrical, it seems the 
> temperature profile never changes, unless I go to extremely small time steps. 
> That strikes me as odd. What do you think?
> 
> Also, the shifting profile seems to reverse, with the left boundary condition 
> dropping to ~300K over time while in Cartesian coordinates, the temperature 
> rises to 600K over time (a result I would expect). I've included a copy of 
> the work with the changes you've suggested previously. If you look at lines 
> 23/24, you can toggle the cylindrical grid on and off, and in lines 30-34, 
> I've included options for the time steps that work for each respective 
> coordinate system. Do you have any suggestions?
> 
> Finally, in reference to the velocity I would like to incorporate, I 
> understand the difference between Cell Variables and Face Variables, but why 
> is the rank of the velocity -1? What does the Face Variable rank indicate?
> 
> Thank you,
> Dan
> 
> On Thu, Apr 11, 2019 at 8:14 AM Guyer, Jonathan E. Dr. (Fed) via fipy 
>  wrote:
> 
> 
> > On Apr 10, 2019, at 4:42 PM, Daniel DeSantis  wrote:
> > 
> > 1) Set a different Cp, rho, and k in just the PCM domain when the 
> > temperature in that domain crosses over a certain melt temperature (350K). 
> > I tried an if statement inside the solving loop and I think that has 
> > worked, based on some print testing I did in the loop. I just wanted to get 
> > your opinion and see if that was the right way to go.
> 
> Seems reasonable, as long as you're calling `.setValue()` and not redefining 
> Cp, rho, and k. 
> 
> In fact, I wouldn't use an `if`:
> 
> >>> for step in range(steps):
> ... T.updateOld()
> ... eq.solve(dt=dt)
> ... rho.setValue(rho_melt, where=PCM & (T > 350))
> 
> 
> > 2) I'd like to move this to cylindrical coordinates with the lengths being 
> > radii. I'm not sure if the cylindrical grid is working though. And if it 
> > isn't, is there a way to convert the diffusion equation into something that 
> > would solve the problem in Cartesian? More specifically, how would you 
> > write an appropriate equation for the heat transfer of a radial system in 
> > Cartesian coordinates? In short, how would you write this:
> > 
> > in FiPy?
> 
> The CylindricalGrids work fine, except for taking the gradient of the field, 
> which is an unusual need.
> 
> > 
> > 3) Ideally, I would move this to a 2D system which is the most confusing to 
> > me. In a 2D system, heat would be transmitted radially while air would be 
> > flowing axially. The air would cool as it passes through the tube. The 
> > diffusion term in the axial direction would be significantly lower than the 
> > convection term. Can I use the same heat transfer equation you've suggested 
> > slightly modified? I would guess the equation to be something like this:
> > 
> > eq = TransientTerm(coeff = rho*Cp,var = T) + 
> > PowerLawConvectionTerm(coeff=rho*Cp*v,var = T) == DiffusionTerm(coeff=k,var 
> > = T)
> > 
> > s.t. v = velocity of the air.
> 
> Looks OK
> 
> > I would also think that I would have to set the value of v to 0 at the wall 
> > and beyond, which means v would be a CellVariable like rho and k. 
> 
> Actually, v should be a rank-1 FaceVariable.
> 
> Anisotropic diffusion is supported in FiPy (see 
> https://www.ctcms.nist.gov/fipy/examples/diffusion/generated/examples.diffusion.anisotropy.html),
>  but are you really sure you have lower axial diffusivity? It seems t

Re: A very basic question

[Guyer, Jonathan E. Dr. (Fed) via fipy]

That's not unsurprising.
The scipy solvers are terribly slow *and* the pysparse LU solver is quite fast, 
but uses a lot of memory.


From: fipy-boun...@nist.gov  on behalf of Dario Panada 

Sent: Wednesday, April 17, 2019 12:03 PM
To: FIPY
Subject: A very basic question

Hello,

I apologize in advance as this is probably a very basic question. I recently 
changed from the default solver  (I believe this is SciPy) to PySparse by 
running my script with the --pysparse flag.

A 3D diffusion problem that was solved in ~1 minute is now solved in ~5-10 
seconds. I know PySparse is meant to be faster, but is it reasonable to expect 
an improvement of this magnitude or should I check some config/installation?

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

Re: Setting CellVariable values

[Guyer, Jonathan E. Dr. (Fed) via fipy]

> On Apr 10, 2019, at 11:12 AM, Dario Panada  wrote:
> 
> In my case, as I just have only one dimension, using sourceGrid.value[i] or 
> sourceGrid[...,i] should be equivalent though?

Yes


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

Re: Setting CellVariable values

[Guyer, Jonathan E. Dr. (Fed) via fipy]

> On Apr 8, 2019, at 6:38 PM, Dario Panada  wrote:

> DP: I guess what confuses me here is the [..., i] syntax on the CellVariable 
> object thought. 

FiPy is built on NumPy. `...` or Ellipsis means "all the indices except for the 
one specified". FiPy stores cells in the last index of the internal NumPy 
array. A CellVariable can potentially be a field of vectors or tensors, so 
there could be more leading dimensions. Writing `[..., i]` ensures you're 
inserting data where you want.

https://docs.scipy.org/doc/numpy/reference/arrays.indexing.html?highlight=ellipsis%20expand


> Between this approach and .value, which one would you recommend?

>>> i = np.ravel_multi_index([coordinate[0], coordinate[1], coordinate[2]], 
>>> (20, 20, 20))
>>> sourceGrid[..., i] = sourceRate


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

Re: Setting CellVariable values

[Guyer, Jonathan E. Dr. (Fed) via fipy]

> On Apr 8, 2019, at 4:09 PM, Dario Panada  wrote:
> 
> DP: That would be diffusion of solubles from blood vessels (endothelial 
> cells). Specifically, glucose or oxygen. It wouldn't change significantly be 
> increasing it to a 40x40x40 grid, you'd just be simulating a larger section 
> of tissue.

Blood vessels aren't 20x20x20 grids and don't have locations like (1,2,3) in 
them. What I'm trying (and failing) to get at is that you have some physical 
locations, in micrometers or furlongs or lightyears, that you actually care 
about. It is better in FiPy to think about the things that you *really* care 
about and not try to second guess what FiPy cares about. Grid locations are an 
implementation detail. If you do grid convergence studies (and you should), 
then your grid locations will all change, but the physical definitions of them 
won't.

> DP: English is my first language but I think that's some tough sarcasm to 
> tell me not to do that. In that case, I'll happily take advice on proper ways 
> of achieving the same result so as not to cumber the dev team with 
> unnecessary refactoring.

I concede the sarcasm. I explained the proper way of achieving the same result 
in my first reply and the discussion kept going on about `_array`. Don't use 
`var._array`. Use `var` or `var.value`.

> So, in essence, I have a 20x20x20 grid of values. I want to somehow input 
> these values into a 20x20x20 structured mesh in the CellVariable object. The 
> fact that the approach might not work in unstructured meshes isn't concerning 
> because I don't require that feature. Setting values in _array appears to 
> work but is not an acceptable solution. From the previous exchange with 
> Martin, using the value property appears possible, although raveling indexes 
> has also been discouraged. So, any advice?

As I said in my first response:

>>> i = np.ravel_multi_index([coordinate[0], coordinate[1], coordinate[2]], 
>>> (20, 20, 20))
>>> sourceGrid[..., i] = sourceRate

Martin's suggestion of 

>>> sourceView = sourceGrid.value.reshape(20, 20, 20)
>>> sourceView[coordinate] = sourceRate

is interesting. It's a little fragile (if the internal storage was strided for 
some reason, then I don't think it would work), but it's worth considering and 
I, at least, find it clearer.

Raveling is not discouraged per se. Martin's `reshape` amounts to the same 
thing.


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

Re: Setting CellVariable values

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Martin -

That's interesting that `u.value.reshape(Nz,Ny,Nx)` gives you a view on the 
CellVariable's value. I'd say it's not 100% reliable that it always will, but 
it probably will. The result is certainly easier to read than juggling around 
with `ravel_multi_index`.

- Jon


> On Apr 8, 2019, at 12:01 PM, Martinus WERTS  
> wrote:
> 
> Dear Dario,
> 
> I am currently using Fipy for a slightly different diffusion-reaction 
> problem. 
> 
> I use a CellVariable on the same grid for the (spatially-dependent) rate 
> constant. One can set its values in a "numpy-vectorized" fashion by accessing 
> the "value" property of the CellVariable.
> 
> By using a Boolean expression for indexing the "value" vector one can address 
> individual elements.
> 
> Here are bits of code that illustrate the approach. It sets the "capture 
> rate" to Kcap inside a sphere of radius R. Outside the sphere, "capture rate" 
> is zero.
> 
> # create grid (one octant, using symmetry)
> mesh = UniformGrid3D(nx=Nx, ny=Ny, nz=Nz,
>   dx=sx/Nx, dy=sy/Ny, dz=sz/Nz,
>  origin=[[0.],[0.],[0.]] )
> X,Y,Z = mesh.cellCenters
> 
> # variables
> u = CellVariable(name="particles",
>mesh=mesh,
>value=0.)
> k = CellVariable(name="capture rate",
>   mesh=mesh,
>   value=0.)
> 
> # equation
> eq = TransientTerm(var = u) == DiffusionTerm(coeff = Dcoeff, var = u) - 
> k*u
> 
> # I skip the boundary conditions here to keep this message compact
> 
> # initial conditions for u; setting value for rate constant
> u.value=Ceq
> k.value[(X**2 + Y**2 + Z**2< Rcap**2)] = Kcap
> 
> 
> I also found that it is possible to access the elements on this regular 3D 
> grid via a "reshaped" version of the array
> 
> uvol = u.value.reshape(Nz,Ny,Nx)
> 
> (...)
> 
> uvol[:,0,:] += np.sum(vvol, axis=1)
> 
> This approach, however, requires that one does the book-keeping of the 
> coordinate system oneself, and relies on the specific way that the data is 
> organized by FiPy.
> 
> Best wishes,
> Martin
> 
> 
> 
> 
> 
> On 08/04/2019 17:30, Dario Panada wrote:
>> Hello,
>> 
>> Many thanks for your reply.
>> 
>> Yes, let me provide a bit more context.
>> 
>> I two initial numpy grids (n*n*n) where each value corresponds to a 
>> source/sink. Eg: Given my source grid and coordinates (1,2,3) having value 
>> 5, I want to set such value as a source in FiPy. Currently I am dong that 
>> by, for each   such coordinate, finding the corresponding ravelled 
>> index and setting it in _array, as snippet in my previous message;
>> 
>>  i = np.ravel_multi_index([coordinate[0], coordinate[1], coordinate[2]], 
>> (20, 20, 20))
>> 
>> sourceGrid._array[i] = sourceRate
>> sinkGrid._array[i] = sinkRate
>> 
>> I suppose I could build the entire vector of sources before and then doing a 
>> single assignment to _array, but again you   correctly mentioned 
>> that relying on that is bad practice.
>> 
>> You mention:
>> 
>> sourceGrid[..., i] = sourceRate
>> 
>> Can I just please confirm what data type sourceGrid is? In the context of 
>> defining the equation
>> 
>> eq = TransientTerm() == DiffusionTerm(coeff=D) + sourceGrid - sinkGrid
>> 
>> Can sourceGrid/sinkGrid just be numpy arrays or even simple python lists? I 
>> was under the impression they had to be CellVariable objects but could be 
>> wrong.
>> 
>> Kind Regards,
>> Dario
>> 
>> 
>> 
>> On Mon, Apr 8, 2019 at 3:04 PM Guyer, Jonathan E. Dr. (Fed) via fipy 
>>  wrote:
>> Iterating over a mesh with a Python `for` loop is, as you've found, an 
>> incredibly inefficient way to do things. FiPy, like numpy it relies on, is 
>> intended to be used with vectorized operations. 
>> 
>> As far as your approach, things that start with `_` in Python are internal 
>> implementation details and you should not depend on them. If you find cases 
>> in FiPy that absolutely require that you access `some._propertyName` or 
>> `some._methodName()`, then please file an issue explaining your need so that 
>> we can provide a public interface.
>> 
>> In this case, there's no need to access `_array`. Just write
>> 
>> >>> sourceGrid[..., i] = sourceRate
>> >>> sinkGrid[..., i] = sinkRate
>> 
>> HOWE

Re: Setting CellVariable values

[Guyer, Jonathan E. Dr. (Fed) via fipy]

> On Apr 8, 2019, at 11:30 AM, Dario Panada  wrote:

> I two initial numpy grids (n*n*n) where each value corresponds to a 
> source/sink. Eg: Given my source grid and coordinates (1,2,3) having value 5, 
> I want to set such value as a source in FiPy.

That wasn't my question. When you publish your research, is your paper going to 
say "We put a source at array index (1,2,3)"? Why did you put it there? What 
physical process would you be modeling by having a source at index (1,2,3)? 
Would that physical process be changed by modeling a 40x40x40 grid?

> I suppose I could build the entire vector of sources before and then doing a 
> single assignment to _array, but again you correctly mentioned that relying 
> on that is bad practice.

If you assign to _array, I will change the FiPy codebase for the sole, spiteful 
purpose of breaking your code.

> You mention:
> 
> sourceGrid[..., i] = sourceRate
> 
> Can I just please confirm what data type sourceGrid is? In the context of 
> defining the equation

sourceGrid is a CellVariable

> 
> eq = TransientTerm() == DiffusionTerm(coeff=D) + sourceGrid - sinkGrid
> 
> Can sourceGrid/sinkGrid just be numpy arrays or even simple python lists? I 
> was under the impression they had to be CellVariable objects but could be 
> wrong.

sourceGrid and sinkGrid must be CellVariables. 


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

Re: Setting CellVariable values

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Iterating over a mesh with a Python `for` loop is, as you've found, an 
incredibly inefficient way to do things. FiPy, like numpy it relies on, is 
intended to be used with vectorized operations. 

As far as your approach, things that start with `_` in Python are internal 
implementation details and you should not depend on them. If you find cases in 
FiPy that absolutely require that you access `some._propertyName` or 
`some._methodName()`, then please file an issue explaining your need so that we 
can provide a public interface.

In this case, there's no need to access `_array`. Just write

>>> sourceGrid[..., i] = sourceRate
>>> sinkGrid[..., i] = sinkRate

HOWEVER, you are still relying on an internal implementation detail, 
specifically that a Grid is an array with known fastest and slowest varying 
axes. We have in FiPy's history switched from Fortran to C ordering, and we 
might conceivably switch back at some point. Further, if you every wanted to 
run your script on an unstructured mesh, then your system wouldn't work at all.

`sourceCoords` presumably comes from some definition in terms of geometry 
rather than discrete mesh indices. FiPy is intended to work best with those 
geometric descriptions. If you described where `sourceCoords` came from, we 
could help with a more FiPyish way to get what you want.



> On Apr 6, 2019, at 9:02 AM, Dario Panada  wrote:
> 
> Good Afternoon (Morning) to all,
> 
> I have an equation of type
> 
> eq = TransientTerm() == DiffusionTerm(coeff=D) + sourceGrid - sinkGrid
> 
> Where sourceGrid and sinkGrid are derived from values in a 3D grid.
> 
> Is there any downside to declaring the grids as 
> 
> sourceGrid = CellVariable(name="source", mesh=Grid3D(dx=1, dy=1, dz=1, nx=20, 
> ny=20, nz=20))
> sinkGrid = CellVariable(name="sink", mesh=Grid3D(dx=1, dy=1, dz=1, 
> nx=20, ny=20, nz=20))
> 
> And populating them as:
> 
>  i = np.ravel_multi_index([coordinate[0], coordinate[1], coordinate[2]], (20, 
> 20, 20))
> 
> sourceGrid._array[i] = sourceRate
> sinkGrid._array[i] = sinkRate
> 
> The original procedure I was using (given below) where I called .setValue on 
> each coordinate is extremely time-consuming. Results seem to align, but of 
> course this doesn't mean it's right... Or if it's wrong, any specific advice 
> on how to achieve this?
> 
> Thanks,
> Dario
> 
> Original approach (and there is an equivalent function for setupSinkGrid):
> def setupSourceGrid_(self, sourceCoords, mesh):
> sourceGrid = CellVariable(name="source", mesh=mesh, value=0)
> sourceGrid.setValue(0.)
> for pos, v in sourceCoords.iteritems():
> tmpGrid = [False for _ in range(8000)]
> i = np.ravel_multi_index([pos[0], pos[1], pos[2]], (20, 20, 20))
> tmpGrid[i] = True
> sourceGrid.setValue(v, where=tmpGrid)
> 
> ___
> 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: Setting up 3D Diffusion

[Guyer, Jonathan E. Dr. (Fed) via fipy]

> On Apr 3, 2019, at 6:36 PM, Dario Panada  wrote:
> 
> Many thanks, I think that is making more sense now. I assume I could also 
> change D to be expressed in terms of 0.042**(2./3) to keep consistency? (It 
> would be a bit of a bizarre setup I admit..)

If you choose to scale things on a length of 0.042**(2./3), then you should do 
so for both d(x|y|z) and for D. 

I reiterate, there is no computational benefit to doing so. Further, if it 
matters to you that your cells are 0.042 mm**3, it is unlikely that you'll 
derive any conceptual benefit from a dimensionless representation.

> As a separate question, if not boundary conditions are specified what does 
> this default to? (If anything)

No flux


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

Re: Setting up 3D Diffusion

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Dario -

1) FiPy does have a mechanism for specifying units. See:

https://www.ctcms.nist.gov/fipy/fipy/generated/fipy.variables.html#fipy.variables.variable.Variable
https://www.ctcms.nist.gov/fipy/fipy/generated/fipy.variables.html#fipy.variables.variable.Variable.inBaseUnits
https://www.ctcms.nist.gov/fipy/fipy/generated/fipy.variables.html#fipy.variables.variable.Variable.inUnitsOf

However, they don't propagate through the solvers, so you end up needing to 
express your equations with dimensionless coefficients composed of dimensional 
Variables. I'm not sure that anybody but me has ever tried to use this feature, 
and I don't use it.

I was not suggesting truly dimensional coefficients, though. Just pick a 
self-consistent system, e.g.,

dx = dy = dz = .042**(1./3) # mm
dt = 15.125 # s
D = 0.001 # mm2/s

FiPy doesn't care. You're going to pay the price for multiplying and dividing 
everything by 1, anyway, so you might as well work with terms that are easier 
to think about, at least for me.

2) I did not mean to suggest that the time step doesn't matter. Only that the 
Fourier limit doesn't apply. 
The Fourier limit is associated with *stability*. An explicit discretization 
"blows up" if the Fourier limit is exceeded, but an implicit discretization 
does not. Accuracy may suffer, however. 

This is all covered pretty methodically in examples/diffusion/mesh1D.py.

> On Apr 3, 2019, at 4:35 PM, Dario Panada  wrote:
> 
> Hi Jonathan,
> 
> Many thanks for your quick response.
> 
> Firstly apologies if I'm asking rather basic questions, I'm still new to FiPy 
> and learning. I've read the manual but if you think there are any sections I 
> would benefit from re-reading, or any additional resources, please feel free 
> to point me to them as an answer.
> 
> 1) So how do I specify/enforce units? For example, I'm setting my diffusivity 
> in mm2/s. I could convert this to cm2/s and put that obviously different 
> value for D. How does FiPy know I've changed the units? Or should I make my 
> units consistent with the spatial discretization? (Ie: If I use mm3 then my 
> diffusivity should use mm2.) But then how about the time unit? What if I 
> converted from mm2/s to mm2/hour?
> 
> 2) In my case, changing dt does affect the final output all other things 
> being equal. (However, I am using integer for dx etc. Maybe that's why?)
> 
> Kind Regards,
> Dario
> 
> On Wed, Apr 3, 2019 at 8:48 PM Guyer, Jonathan E. Dr. (Fed) via fipy 
>  wrote:
> Dario -
> 
> - FiPy's DiffusionTerm is implicit, so there is no Fourier limit on your time 
> step.
> 
> - There's no particular advantage to scaling length and time to 1
> 
> - Be sure to set dx = dy = dz = 1., a float, not dx = dy = dz = 1, an integer
> 
> - Jon
> 
> > On Apr 3, 2019, at 11:28 AM, Dario Panada  wrote:
> > 
> > Hello,
> > 
> > I am trying to use FiPy to build a system to simulate oxygen diffusion in 
> > tissues in 3D.
> > 
> > My grid is a 20x20x20 mesh, defined as:
> > 
> > mesh=Grid3D(dx=dx,dy=dy,nx=nx,ny=ny, dz=dz, nz=nz)
> > 
> > Where nx = ny = nz = 20 and dx = dy = dz = 1. This approach is taken from 
> > examples.diffusion.mesh1D, where nx was set to 50 and dx to 1 to represent 
> > unity.
> > 
> > I setup my equation as:
> > 
> > eq=TransientTerm()==DiffusionTerm(coeff=D) + sourceGrid - sinkGrid
> > 
> > My oxygen diffusion coefficient (D) is 0.001 mm2/s. Each cell is my grid 
> > corresponds to 0.042 mm3. So (Δx)^3 = 0.042mm^3 which implies (Δx^2) 
> > ~=0.121 mm2.
> > 
> > I understand that for 3D problems the Fourier number (Fo) has to be less 
> > than or equal to 1/8.
> > 
> > With Fo = DΔt/(Δx^2)  <= 1/8 so Δt <= (Δx^2)/(8D) where replacing values I 
> > get  Δt <= 15.125 .
> > 
> > From the above, would it be sensible to setup my script as?
> > ---
> > nx = ny = nz = 20
> > dx = dy = dz = 1
> > dt = 1
> > D = 0.121
> > mesh=Grid3D(dx=dx,dy=dy,nx=nx,ny=ny, dz=dz, nz=nz)
> > 
> > phi=CellVariable(name="solutionvariable",mesh=mesh,value=0.)
> > 
> > eq=TransientTerm()==DiffusionTerm(coeff=D) + sourceGrid - sinkGrid
> > 
> > eq.solve(var=phi,dt=dt)
> > ---
> > 
> > Or am I missing something/have interpreted something wrong?
> > 
> > Kind Regards,
> > Dario
> > ___
> > 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 ]


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

Re: Setting up 3D Diffusion

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Dario -

- FiPy's DiffusionTerm is implicit, so there is no Fourier limit on your time 
step.

- There's no particular advantage to scaling length and time to 1

- Be sure to set dx = dy = dz = 1., a float, not dx = dy = dz = 1, an integer

- Jon

> On Apr 3, 2019, at 11:28 AM, Dario Panada  wrote:
> 
> Hello,
> 
> I am trying to use FiPy to build a system to simulate oxygen diffusion in 
> tissues in 3D.
> 
> My grid is a 20x20x20 mesh, defined as:
> 
> mesh=Grid3D(dx=dx,dy=dy,nx=nx,ny=ny, dz=dz, nz=nz)
> 
> Where nx = ny = nz = 20 and dx = dy = dz = 1. This approach is taken from 
> examples.diffusion.mesh1D, where nx was set to 50 and dx to 1 to represent 
> unity.
> 
> I setup my equation as:
> 
> eq=TransientTerm()==DiffusionTerm(coeff=D) + sourceGrid - sinkGrid
> 
> My oxygen diffusion coefficient (D) is 0.001 mm2/s. Each cell is my grid 
> corresponds to 0.042 mm3. So (Δx)^3 = 0.042mm^3 which implies (Δx^2) ~=0.121 
> mm2.
> 
> I understand that for 3D problems the Fourier number (Fo) has to be less than 
> or equal to 1/8.
> 
> With Fo = DΔt/(Δx^2)  <= 1/8 so Δt <= (Δx^2)/(8D) where replacing values I 
> get  Δt <= 15.125 .
> 
> From the above, would it be sensible to setup my script as?
> ---
> nx = ny = nz = 20
> dx = dy = dz = 1
> dt = 1
> D = 0.121
> mesh=Grid3D(dx=dx,dy=dy,nx=nx,ny=ny, dz=dz, nz=nz)
> 
> phi=CellVariable(name="solutionvariable",mesh=mesh,value=0.)
> 
> eq=TransientTerm()==DiffusionTerm(coeff=D) + sourceGrid - sinkGrid
> 
> eq.solve(var=phi,dt=dt)
> ---
> 
> Or am I missing something/have interpreted something wrong?
> 
> Kind Regards,
> Dario
> ___
> 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: Using a different Matplotlib backend on a per-script basis

[Guyer, Jonathan E. Dr. (Fed) via fipy]

I think option 3 is what you want. Before import fipy or anything else, start 
your script with 
```
import matplotlib
matplotlib.use('backend')  
```

> On Mar 13, 2019, at 9:43 AM, Christoph Margenfeld 
>  wrote:
> 
> Hello,
> 
> as mentioned in the FiPy FAQ, a different Matplotlib backend has to be 
> used when exporting images from the MatplotlibViewer class without any 
> output to the screen.
> 
> From the Matplotlib documentation (at 
> https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmatplotlib.org%2Ftutorials%2Fintroductory%2Fusage.html%23what-is-a-backenddata=02%7C01%7Cjonathan.guyer%40nist.gov%7Cfcdca20d85b343ceac4b08d6a7ba19f0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636880815078320111sdata=%2B0YF4KH4MUJJcHVjxm5RXUpE%2BYUdSoLLcWEn6HAlmsE%3Dreserved=0),
>  
> there are three ways to select a backend. The first two would involve 
> setting it in a .matplotlibrc file or as an environment variable. 
> However, that would affect all scripts run in that particular 
> environment, which I do not want to do. The third approach is setting 
> matplotlib.use('backend').
> 
> How can I select a Matplotlib backend for a certain MatplotlibViewer 
> without affecting any other scripts run from my environment?
> 
> Thank you!
> 
> Best regards,
> Christoph Margenfeld
> ___
> 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: source term that is a discontinuous function of time

[Guyer, Jonathan E. Dr. (Fed) via fipy]

The issue is that while stepFunc() is a Python function, it is not a Variable 
operator expression as far as FiPy is concerned. FiPy Variable operator 
expressions tend to be things that can be expressed as arithmetic expressions. 
Python conditionals don't work; greater/less-than expressions do.

It is possible to construct your own Variable class that can calculate 
something unusual, but I find this is seldom necessary. See the source code in 
fipy/variables for noiseVariable.py (and all of the ...NoiseVariable.py 
subclasses), modularVariable.py, histogramVariable.py for some examples. 
Generally, you need to override the _calcValue() method to perform the 
calculation you need. Usually I find it's easier and more maintainable to write 
an arithmetic expression for what I need.

Whether the return value is an integer or float has no bearing on this; a float 
value is simply correct from the standpoint of evaluating the PDE. It might not 
matter, but integers can behave badly at unpredictable times.

> On Feb 1, 2019, at 10:20 AM, Bill Greene  wrote:
> 
> Your suggestion certainly works and I appreciate the quick response.
> 
> However, in general, I would like to define more complicated functions of 
> time that are best
> implemented in a function. So I am still interested in WHY the function 
> approach doesn't
> work. Is there a way to tell FiPy to call that function whenever the time 
> Variable is changed?
> If there is a manual section you can point me to, that would be great. 
> 
> (I changed the function to return a floating point number instead of an 
> integer but it is still
> being treated as a constant.)
> 
> Thanks,
> 
> Bill
> 
> On Fri, Feb 1, 2019 at 9:40 AM Guyer, Jonathan E. Dr. (Fed) via fipy 
>  wrote:
> `time` is a Variable as FiPy understands it, but stepFunc() simply returns an 
> integer, so eqI is defined with a source that is the integer 0.
> 
> I'd try
> 
> eqI = fipy.TransientTerm(coeff=1.) == ((time < 0.1) * 0. + (time >= 0.1) * 1.)
> 
> > On Feb 1, 2019, at 6:05 AM, Bill Greene  wrote:
> > 
> > I am trying to solve an equation where the source term is
> > a discontinuous function of time. I have followed examples
> > where the source term is a simple, continuous function of time
> > and these appear to work correctly. 
> > 
> > The key parts of my code are shown below:
> > 
> > def stepFunc(t):
> >   if(t.value<.1):
> > s = 0
> >   else:
> > s=1
> >   print('t=', t, 's=', s)
> >   return s
> >   
> > time = fipy.Variable(0., cached=1)
> > eqI = fipy.TransientTerm(coeff=1.) == stepFunc(time)
> > 
> > t = 0
> > for step in range(steps):
> >   time.setValue(t+dt/2.)
> >   eqI.solve(var=u, dt=dt)
> >   t += dt 
> >   
> > The function stepFunc appears to be called only once and the solution
> > indicates that s=0 for the entire solution time.
> > 
> > I thought that the cached option on the Variable object might affect this
> > behavior but when I set it to zero, I get an error message that I don't 
> > understand.
> > 
> > Any help will be much appreciated.
> > 
> > Bill Greene
> > 
> > ___
> > 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 ]


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

Re: source term that is a discontinuous function of time

[Guyer, Jonathan E. Dr. (Fed) via fipy]

`time` is a Variable as FiPy understands it, but stepFunc() simply returns an 
integer, so eqI is defined with a source that is the integer 0.

I'd try

eqI = fipy.TransientTerm(coeff=1.) == ((time < 0.1) * 0. + (time >= 0.1) * 1.)

> On Feb 1, 2019, at 6:05 AM, Bill Greene  wrote:
> 
> I am trying to solve an equation where the source term is
> a discontinuous function of time. I have followed examples
> where the source term is a simple, continuous function of time
> and these appear to work correctly. 
> 
> The key parts of my code are shown below:
> 
> def stepFunc(t):
>   if(t.value<.1):
> s = 0
>   else:
> s=1
>   print('t=', t, 's=', s)
>   return s
>   
> time = fipy.Variable(0., cached=1)
> eqI = fipy.TransientTerm(coeff=1.) == stepFunc(time)
> 
> t = 0
> for step in range(steps):
>   time.setValue(t+dt/2.)
>   eqI.solve(var=u, dt=dt)
>   t += dt 
>   
> The function stepFunc appears to be called only once and the solution
> indicates that s=0 for the entire solution time.
> 
> I thought that the cached option on the Variable object might affect this
> behavior but when I set it to zero, I get an error message that I don't 
> understand.
> 
> Any help will be much appreciated.
> 
> Bill Greene
> 
> ___
> 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 ]

FiPy developers unresponsive during federal government shutdown

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Due to the federal government shutdown, the FiPy developers are unable to 
access e-mails. We will respond to your questions in a timely manner once funds 
have been appropriated and the shutdown ends. We apologize for any 
inconvenience and look forward to assisting you with FiPy once operations 
resume.

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

Re: how to apply convection boundary condition in 2D?

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Drew -

I'm glad we were able to get things working for you.

I recommend learning git/github just because I think it'll help you keep track 
of your own work. Jumbles of renamed files are a sure-fire way to lose things. 
I recommend the [Software Carpentry 
lesson](http://swcarpentry.github.io/git-novice/); it only takes a few hours.

- Jon

> On Dec 18, 2018, at 12:43 AM, Drew Davidson  wrote:
> 
> Hi Dr. Guyer,
> 
> I updated my code with your changes.  It now matches the analytical solution 
> pretty well, after several grid refinements.  This is of course not a 
> comprehensive test.
> 
> The Python script: 
> https://github.com/cashTangoTangoCash/Convection2DFiPyExample01/blob/master/ConvectionTestProblem2D_01_20181215Version.py
> 
> A report showing agreement between FiPy and analytical solution:  
> https://github.com/cashTangoTangoCash/Convection2DFiPyExample01/blob/master/Report20181216.pdf
> 
> The README.md of my repo has been updated to provide a better explanation of 
> what is going on.
> 
> I apologize for not learning git/github well enough to have github properly 
> track changes between us as we went along.  Instead, I put comments at the 
> top of my scripts to document how I was looking at your code and 
> documentation.
> 
> Thanks
> 
> 
> On Fri, Dec 14, 2018 at 8:20 PM Guyer, Jonathan E. Dr. (Fed) via fipy 
>  wrote:
> Drew -
> 
> I had found the same sign error in the denominator. You're also correct that 
> the units didn't agree. Multiplying by the face areas is redundant to taking 
> the divergence.
> 
> I've updated our notes:
> 
> https://github.com/usnistgov/fipy/blob/dd3420fb71884d74850051ad2280bff525301824/documentation/USAGE.rst
> 
> and your latest code:
> 
> https://github.com/guyer/Convection2DFiPyExample01/commit/ca59e8955319545f9965705c8fadfcbb5abd5951
> 
> With these changes, the results look much more plausible.
> 
> - Jon
> 
> > On Dec 12, 2018, at 1:22 PM, Drew Davidson  wrote:
> > 
> >  Hi Dr. Guyer,
> > 
> > I looked over your more recent documentation:
> > https://github.com/usnistgov/fipy/blob/70b72b7abb267c85ada47886b8b3573e1819fffc/documentation/USAGE.rst
> > 
> > I am embarrassed I did not understand how to choose values for a and b in 
> > the Robin condition before.
> > 
> > I also cloned your repo to my local computer and ran it:
> > https://github.com/guyer/Convection2DFiPyExample01
> > 
> > When I run the code in your repo, the viewer does show a variation in T 
> > with respect to r, but the size of that variation is extremely tiny. 
> > Essentially, the solution is pinned at the initial temperature. The 
> > variation also has the wrong sign (solid object is warming up), as the 
> > ambient air is colder than the solid object (T_infinity < T_initial), and 
> > the solid object should be cooling down. Maybe this is due to confusion I 
> > sowed by having var be T minus T_infinity; sorry.
> > 
> > I tried another script in my repo:
> > 
> > https://github.com/cashTangoTangoCash/Convection2DFiPyExample01/blob/master/ConvectionTestProblem2D_01_20181211Version.py
> > 
> > This script is upgraded in that now, the log file contains information 
> > about the solution (max and min temperatures). I obtain max and min 
> > temperatures using var.value.min() and var.value.max() in order to rule out 
> > goof-ups in my get_solution_along_ray function.
> > 
> > The solution variable var is now exactly the temperature, in order to get 
> > rid of the previous source of confusion in which var was T minus T_infinity.
> > 
> > The solution in my script is still pinned at the initial temperature. This 
> > persists even if I crank up the convection coefficient to a huge value 
> > (keep multiplying it by 1000 over and over and still seeing solution pinned 
> > at initial condition).
> > 
> > I made handwritten notes on top of a pdf I made via Kile Editor of your 
> > more recent documentation:
> > 
> > https://github.com/cashTangoTangoCash/Convection2DFiPyExample01/blob/master/RobinBoundaryConditionsFiPyUsage20181211_Annot_CTTC.pdf
> > 
> > It seems to me that the units of the source terms should match the units of 
> > the terms in the partial differential equation for heat conduction. I 
> > thought that is how it worked from the FiPy examples, but I haven’t gone 
> > back and made sure. I find that for the first source term RobinCoeff*g, the 
> > units don’t seem to match the units of the terms in the PDE for heat 
> > conduction (I didn’t check the 2nd source term since it should be the same 
> > situation). I did this in kind o

Re: how to apply convection boundary condition in 2D?

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Drew -

I had found the same sign error in the denominator. You're also correct that 
the units didn't agree. Multiplying by the face areas is redundant to taking 
the divergence.

I've updated our notes:

https://github.com/usnistgov/fipy/blob/dd3420fb71884d74850051ad2280bff525301824/documentation/USAGE.rst

and your latest code:

https://github.com/guyer/Convection2DFiPyExample01/commit/ca59e8955319545f9965705c8fadfcbb5abd5951

With these changes, the results look much more plausible.

- Jon

> On Dec 12, 2018, at 1:22 PM, Drew Davidson  wrote:
> 
>  Hi Dr. Guyer,
> 
> I looked over your more recent documentation:
> https://github.com/usnistgov/fipy/blob/70b72b7abb267c85ada47886b8b3573e1819fffc/documentation/USAGE.rst
> 
> I am embarrassed I did not understand how to choose values for a and b in the 
> Robin condition before.
> 
> I also cloned your repo to my local computer and ran it:
> https://github.com/guyer/Convection2DFiPyExample01
> 
> When I run the code in your repo, the viewer does show a variation in T with 
> respect to r, but the size of that variation is extremely tiny. Essentially, 
> the solution is pinned at the initial temperature. The variation also has the 
> wrong sign (solid object is warming up), as the ambient air is colder than 
> the solid object (T_infinity < T_initial), and the solid object should be 
> cooling down. Maybe this is due to confusion I sowed by having var be T minus 
> T_infinity; sorry.
> 
> I tried another script in my repo:
> 
> https://github.com/cashTangoTangoCash/Convection2DFiPyExample01/blob/master/ConvectionTestProblem2D_01_20181211Version.py
> 
> This script is upgraded in that now, the log file contains information about 
> the solution (max and min temperatures). I obtain max and min temperatures 
> using var.value.min() and var.value.max() in order to rule out goof-ups in my 
> get_solution_along_ray function.
> 
> The solution variable var is now exactly the temperature, in order to get rid 
> of the previous source of confusion in which var was T minus T_infinity.
> 
> The solution in my script is still pinned at the initial temperature. This 
> persists even if I crank up the convection coefficient to a huge value (keep 
> multiplying it by 1000 over and over and still seeing solution pinned at 
> initial condition).
> 
> I made handwritten notes on top of a pdf I made via Kile Editor of your more 
> recent documentation:
> 
> https://github.com/cashTangoTangoCash/Convection2DFiPyExample01/blob/master/RobinBoundaryConditionsFiPyUsage20181211_Annot_CTTC.pdf
> 
> It seems to me that the units of the source terms should match the units of 
> the terms in the partial differential equation for heat conduction. I thought 
> that is how it worked from the FiPy examples, but I haven’t gone back and 
> made sure. I find that for the first source term RobinCoeff*g, the units 
> don’t seem to match the units of the terms in the PDE for heat conduction (I 
> didn’t check the 2nd source term since it should be the same situation). I 
> did this in kind of a hurry so maybe I am goofing up. I have not studied the 
> finite volume method, and am just going on a hunch.
> 
> It also seemed to me that there might be a minus sign missing in the 
> RobinCoeff. The solution I get is still pinned at initial condition 
> regardless of a minus sign or no minus sign there.
> 
> Thanks
> 
> On Fri, Dec 7, 2018 at 6:05 PM Guyer, Jonathan E. Dr. (Fed) via fipy 
>  wrote:
> Drew -
> 
> 
> Thanks to your notes, I found a couple of errors in our Robin discussion. As 
> you noted, the units don't work for the conversion of the divergence of gamma 
> grad phi to the sum over faces (midway on page 1 of your notes). The left 
> hand side should be integrated over volume. That line is expressing the 
> discretization of the divergence theorem.
> 
> I also discovered that the .divergence operator in FiPy doesn't work reliably 
> on scalars. There's no real reason it should, but I thought I had convinced 
> myself that it did. As a result, everything in the Robin terms needs to be 
> multiplied by the surface normal 
> 
> Those changes to the FiPy documentation are 
> [here](https://github.com/usnistgov/fipy/pull/615) for now.
> 
> Beyond addition that, there are some changes necessary to put your boundary 
> condition into Robin form. The point of the Robin condition is that it ties 
> the gradient of the field to the value of the field. 
> So, g isn't h(T - T_inf) / (-k); it's just -h T_inf / (-k). 
> Likewise, \vec{a} isn't zero. Rather, \hat{n}\cdot\vec{a} = h/(-k). 
> 
> Here are the changes I made to your script to reflect these changes:
> https://github.com/cashTangoTangoCash/Convection2DFiPyExample01/compare/master..

Re: how to apply convection boundary condition in 2D?

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Drew -


Thanks to your notes, I found a couple of errors in our Robin discussion. As 
you noted, the units don't work for the conversion of the divergence of gamma 
grad phi to the sum over faces (midway on page 1 of your notes). The left hand 
side should be integrated over volume. That line is expressing the 
discretization of the divergence theorem.

I also discovered that the .divergence operator in FiPy doesn't work reliably 
on scalars. There's no real reason it should, but I thought I had convinced 
myself that it did. As a result, everything in the Robin terms needs to be 
multiplied by the surface normal 

Those changes to the FiPy documentation are 
[here](https://github.com/usnistgov/fipy/pull/615) for now.

Beyond addition that, there are some changes necessary to put your boundary 
condition into Robin form. The point of the Robin condition is that it ties the 
gradient of the field to the value of the field. 
So, g isn't h(T - T_inf) / (-k); it's just -h T_inf / (-k). 
Likewise, \vec{a} isn't zero. Rather, \hat{n}\cdot\vec{a} = h/(-k). 

Here are the changes I made to your script to reflect these changes:
https://github.com/cashTangoTangoCash/Convection2DFiPyExample01/compare/master...guyer:master

I think I got your normalized temperature accounted for properly, and put the 
thermal diffusivity and convection coefficient in the proper places, but it's 
worth checking through.

With these changes, the temperature field is now rotationally symmetric (it 
wasn't before, which is why I had to multiply by the normal before taking the 
divergence). 

Heat seems to be fluxing in from the outside, so I probably have the sign wrong.

I don't have Octave, so I have no idea how this compares with your analytical 
solution.

- Jon

> On Dec 4, 2018, at 2:34 PM, Drew Davidson  wrote:
> 
>  Hi Dr. Guyer,
> 
> First I tried getting rid of the square brackets in 
> ConvectionTestProblem2D_01.py (commit ‘changed square brackets to parenthesis 
> in convection BC, but get same…’), but results are the same (still wrong).
> 
> Next:
> As you directed, I took a look at:
>  
> https://github.com/usnistgov/fipy/blob/develop/documentation/USAGE.rst#applying-robin-boundary-conditions
> 
> Firefox was showing me raw latex rather than human-readable equations at that 
> web address, so I made a version I could read using the kile editor:
> https://github.com/cashTangoTangoCash/Convection2DFiPyExample01/blob/master/RobinBoundaryConditionsFiPyUsage.pdf
> 
> That material is rather challenging for me. I took a stab at it, resulting in:
> commit: ‘made a first attempt at a formulation in view of suggestions by fipy 
> …’
> 
> ConvectionTestProblem2D_01_2ndTry.py
> https://github.com/cashTangoTangoCash/Convection2DFiPyExample01/blob/fb47960548650c994eb0c6f990e0db297566e174/ConvectionTestProblem2D_01_2ndTry.py
> 
> a few handwritten notes indicating what I was thinking:
> https://github.com/cashTangoTangoCash/Convection2DFiPyExample01/blob/master/RobinBoundaryConditionsFiPyUsageConvectionBC.pdf
> 
> Here is a bit of the code:
> 
> #ref: 
> https://github.com/usnistgov/fipy/blob/develop/documentation/USAGE.rst#applying-robin-boundary-conditions
> 
> #warning: avoid confusion between convectionCoeff in that fipy documentation, 
> which refers to terms involving "a", and convectionCoeff here, which refers 
> to a heat transfer convection coefficient at a boundary
> 
> Gamma0=D_thermal
> 
> Gamma = FaceVariable(mesh=mesh, value=Gamma0)
> 
> mask=surfaceFaces
> 
> Gamma.setValue(0., where=mask)
> 
> dPf = FaceVariable(mesh=mesh, value=mesh._faceToCellDistanceRatio * 
> mesh.cellDistanceVectors)
> 
> Af = FaceVariable(mesh=mesh, value=mesh._faceAreas)
> 
> #RobinCoeff = (mask * Gamma0 * Af / (dPf.dot(a) + b)).divergence #a is zero 
> in our case
> 
> b=1.
> 
> RobinCoeff = (mask * Gamma0 * Af / b).divergence #a is zero in our case
> 
> #eq = (TransientTerm() == DiffusionTerm(coeff=Gamma) + RobinCoeff * g - 
> ImplicitSourceTerm(coeff=RobinCoeff * mesh.faceNormals.dot(a))) #a is zero in 
> our case
> 
> # g in this formulation is -convectionCoeff/k*var, where var=T-T_infinity
> 
> eq = (TransientTerm() == DiffusionTerm(coeff=Gamma) + 
> ImplicitSourceTerm(RobinCoeff * -convectionCoeff/k))
> 
> 
> Now the solution variable remains stuck at the initial condition, as if the 
> boundary condition is not being applied. I am sort of out of my depth at this 
> point. I was guessing that an ImplicitSourceTerm was the right thing to do, 
> since 'g' in the Robin condition depends on the solution variable.  I did 
> mess around a little in IPython seeing if any terms are coming out all zeros.
> 
> Again, I put everything at 
> https://github.com/cashTangoTangoCash/Convection2DFiPyExample01.
> 
> Thank

Re: semiconductor pn junction, problem with current density

[Guyer, Jonathan E. Dr. (Fed) via fipy]

Peter -

The semiconductor drift-diffusion equations are notoriously challenging to 
solve. As you may well be aware, many people use alternative formulations such 
as pseudo-Fermi-levels and Slotboom variables to mitigate some of the 
difficulties that arise from the enormous range of concentrations. The 
Scharfetter-Gummel discretization is also widely applied to improve the 
convergence of the combined drift and diffusion terms.

The fact that these flux peaks scale as dx**2 is consistent with this being a 
discretization error. Newton iterations would probably help drive down the 
error.

I'm not sure what was intended by terms like 
`(-phi.arithmeticFaceValue).divergence`. Fluxes (and currents) are naturally 
described at the face centers between cells. As such, I'd define these like:

>>> J_n = -mu_n * n.harmonicFaceValue * phi.faceGrad + D_n * n.faceGrad

There is, unfortunately, no easy way to plot the magnitude of this flux. In the 
attached, I manually use Matplotlib to do it.

- Jon


> On Nov 30, 2018, at 10:25 AM, Peter Abele  wrote:
> 
> Hello,
> 
> I am using fipy to simulate semiconductor pn junctions, see the attached 
> python script "01_p_n.py".
> 
> Calculation of the electrical field, the width of the  space charge region, 
> and the potential in the semiconductor looks fine even with biasing.
> Evaluating the current densities (drift and diffusion) for the electrons and 
> holes results in extreme peaks independent of the applied biasing, see 
> "Current_Density.png".
> This graph was calculated with no bias voltage.
> In steady state current density should be constant along the semiconductor. 
> Outside the space charge region the current density looks ok. I even get the 
> exponential current density increase with applied voltage.
> 
> Observation:
> It seems that the current density peaks coincide with the second derivative 
> of the electron and/or hole concentration.
> When I additionally multiply the second derivative of the electron 
> concentration with the electron concentration, I get nearly the same shape as 
> for the current density!
> >>> viewer_n = fipy.Viewer(vars=(n.grad[0].grad[0]*n), title="2. 
> >>> derivative n * n", legend='lower left')
> 
> An other observation is that the peak current densities (j_peak) depends on 
> the mesh size (dx), see "eval.eps".
> It seems that j_peak ~ dx**2!
> 
> Do I see the limit of the numerical calculation due to the extreme change in 
> electron / hole concentration at the border of the space charge region?
> Is the big difference in the cell variables (potential (-10 ... 1) and 
> hole/electron concentration (0 ... 1E24)) a problem?
> Any proposal what I can investigate to get a constant current density along 
> the semiconductor?
> 
> 
> Thanks and best regards
>Peter
> 
> 
> <01_p_n.py>___
> fipy mailing list
> fipy@nist.gov
> http://www.ctcms.nist.gov/fipy
>  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
from __future__ import print_function, division
import fipy
import numpy as np
from matplotlib import pyplot as plt



eps_0 = 8.8542e-12 # Permittivity of free space, F/m
q = 1.6022e-19 # Charge of an electron, C
k = 1.3807e-23 # Boltzmann constant, J/K
T = 300# Temperature, K
Vth   = (k*T)/q# Thermal voltage, eV

N_ap  = 1e24   # Acceptor density in p-type layer, m^-3
N_an  = 0  # Acceptor density in n-type layer, m^-3
N_dp  = 0  # Donor density in p-type layer, m^-3
N_dn  = 1e24   # Donor density in n-type layer, m^-3

mu_n  = 1400.0e-4  # Mobilty of electrons, m^2/Vs
mu_p  =  450.0e-4  # Mobilty of holes, m^2/Vs
D_p   = 1*k*T*mu_p/q   # Hole diffusion constant, m^2/s
D_n   = 1*k*T*mu_n/q   # Electron diffusion constant, m^2/s
eps_r = 11.8   # Relative dielectric constant
n_i_Si = 10E15

# Grenze bei 1E11 !!
tau   = 1E-3

eps = eps_0*eps_r

# 
#  generate mesh 
# 
Lx = 150E-9
dx = .15E-9
nx = int(Lx/dx)

mesh = fipy.Grid1D(dx=dx, nx=nx)
Lcenter = Lx / 2


n   = fipy.CellVariable(mesh=mesh, hasOld=True, name='n')
p   = fipy.CellVariable(mesh=mesh, hasOld=True, name='p')
phi = fipy.CellVariable(mesh=mesh, hasOld=True, name='phi')

rho = fipy.CellVariable(mesh=mesh, name='rho')
Nd  = fipy.CellVariable(mesh=mesh, name='Nd')
Na  = fipy.CellVariable(mesh=mesh, name='Na')


x = mesh.cellCenters[0]

# **
# **
#   Doping profile
# **
# **

Na.setValue((+N_ap + np.sqrt(N_ap**2 + 4*n_i_Si**2))/2, where=(x<=Lcenter))
p.setValue( (+N_ap + np.sqrt(N_ap**2 + 4*n_i_Si**2))/2, where=(x<=Lcenter))
n.setValue( (-N_ap + np.sqrt(N_ap**2 + 4*n_i_Si**2))/2, where=(x<=Lcenter))

Nd.setValue((+N_dn + np.sqrt(N_dn**2 + 4*n_i_Si**2))/2,  where=(x>Lcenter))
n.setValue( (+N_dn + np.sqrt(N_dn**2 + 4*n_i_Si**2))/2,   

Re: Boussinesq Equations

[Guyer, Jonathan E. Dr. (Fed)]

 ny=N, dx=dL, dy=dL)
>>>> # Variables
>>>> T = CellVariable(mesh=mesh, name = 'T', value = T0)
>>>> xVelocity = CellVariable(mesh=mesh, name='Xvelocity', value = 0.)
>>>> zVelocity = CellVariable(mesh=mesh, name='Zvelocity', value = 0.)
>>>> velocity = FaceVariable(mesh=mesh, name='velocity', rank=1)
>>>> # Init Condition
>>>> T.setValue(T0)
>>>> # Boundary Conditions
>>>> T.constrain(Tmax, mesh.facesLeft)
>>>> T.constrain(Tmin, mesh.facesRight)
>>>> # Viewer init conditions
>>>> viewer = None
>>>> if __name__ == '__main__':
>>>>viewer = Viewer(vars=T, datamin=Tmin, datamax=Tmax)
>>>>viewer.plot()
>>>>raw_input("...")
>>>> # Boussinesq equations
>>>> eqX = (TransientTerm(var=xVelocity) + ConvectionTerm (var=xVelocity, 
>>>> coeff=velocity) == 0)
>>>> eqZ = (TransientTerm(var=zVelocity) + ConvectionTerm (var=zVelocity, 
>>>> coeff=velocity) == alpha*g*(T-T0))
>>>> eqT = (TransientTerm(var=T) + ConvectionTerm (var=T, coeff=velocity) == 
>>>> DiffusionTerm(var=T, coeff=DT))
>>>> eq = eqX & eqZ & eqT
>>>> # Solving Boussinesq equations
>>>> timeStepDuration = 0.1*dL**2/(2*DT)
>>>> steps = 50
>>>> sweeps = 5
>>>> for step in range(steps):
>>>>for sweep in range(sweeps):
>>>>eq.sweep(dt=timeStepDuration)
>>>>velocity[0] = xVelocity.arithmeticFaceValue
>>>>velocity[1] = zVelocity.arithmeticFaceValue
>>>>velocity[..., mesh.exteriorFaces.value] = 0.
>>>>if viewer is not None:
>>>>   viewer.plot()
>>>>   plt.pause(0.1)
>>>> raw_input("… ")
>>>> 
>>>> I’d like to obtain something like this :
>>>> 
>>>> 
>>>> Thanks again for your help, maybe Jon again ;-)
>>>> 
>>>> Fabien
>>>> 
>>>> 
>>>>> Le 16 août 2018 à 07:20, fgendr01  a écrit :
>>>>> 
>>>>> Thanks a lot Jon.
>>>>> I appreciate your help.
>>>>> I will try to apply your remarks but I will certainly still need your 
>>>>> help again ;-) to develop the code.
>>>>> 
>>>>> Thanks again.
>>>>> 
>>>>> Fabien
>>>>> 
>>>>>> Le 15 août 2018 à 19:46, Guyer, Jonathan E. Dr. (Fed) 
>>>>>>  a écrit :
>>>>>> 
>>>>>> Fabien -
>>>>>> 
>>>>>> I think the code below should get you going.
>>>>>> 
>>>>>> The changes I made were:
>>>>>> 
>>>>>> - `xVelocity` and `zVelocity` changed to rank-0 CellVariables. FiPy 
>>>>>> *always* solves at cell centers.
>>>>>> - Created a rank-1 FaceVariable to hold the velocity. The cell 
>>>>>> components must be interpolated and manually inserted into this field at 
>>>>>> each sweep.
>>>>>> - Changed the sign of the DiffusionTerm in the heat equation; it's 
>>>>>> unconditionally unstable otherwise
>>>>>> - Slowed down the time steps to better see the evolution
>>>>>> 
>>>>>> The result is not identical to the image you showed, but I think that's 
>>>>>> down to boundary conditions, sign of gravity, etc.
>>>>>> 
>>>>>> - Jon
>>>>>> 
>>>>>> # -*- coding: utf-8 -*-
>>>>>> from fipy import *
>>>>>> import matplotlib.pyplot as plt
>>>>>> # Parameter
>>>>>> L = 1. 
>>>>>> N = 50.
>>>>>> dL = L/N
>>>>>> alpha = 0.0002   # Thermical dilatation
>>>>>> landa = 0.6  # Thermical conductivity
>>>>>> ro0 = 1023.  # Average volumic Mass
>>>>>> g = 10.  # Gravity
>>>>>> # Mesh
>>>>>> mesh = Grid2D(nx=N, ny=N, dx=dL, dy=dL)
>>>>>> # Variables
>>>>>> dT = CellVariable(name = 'dT', mesh = mesh, value = 0.)
>>>>>> xVelocity = CellVariable(mesh=mesh, name='Xvelocity', value = 0.)
>>>>>> zVelocity = CellVariable(mesh=mesh, name='Zvelocity', value = 0.)
>>>>>>

Re: Boussinesq Equations

[Guyer, Jonathan E. Dr. (Fed)]

Fabien -

I think the code below should get you going.

The changes I made were:

- `xVelocity` and `zVelocity` changed to rank-0 CellVariables. FiPy *always* 
solves at cell centers.
- Created a rank-1 FaceVariable to hold the velocity. The cell components must 
be interpolated and manually inserted into this field at each sweep.
- Changed the sign of the DiffusionTerm in the heat equation; it's 
unconditionally unstable otherwise
- Slowed down the time steps to better see the evolution

The result is not identical to the image you showed, but I think that's down to 
boundary conditions, sign of gravity, etc.

- Jon

# -*- coding: utf-8 -*-
from fipy import *
import matplotlib.pyplot as plt
# Parameter
L = 1. 
N = 50.
dL = L/N
alpha = 0.0002  # Thermical dilatation
landa = 0.6 # Thermical conductivity
ro0 = 1023. # Average volumic Mass
g = 10. # Gravity
# Mesh
mesh = Grid2D(nx=N, ny=N, dx=dL, dy=dL)
# Variables
dT = CellVariable(name = 'dT', mesh = mesh, value = 0.)
xVelocity = CellVariable(mesh=mesh, name='Xvelocity', value = 0.)
zVelocity = CellVariable(mesh=mesh, name='Zvelocity', value = 0.)
velocity = FaceVariable(mesh=mesh, name='velocity', rank=1)
# Init Condition
x = mesh.cellCenters[0]
dT.setValue(1.)
dT.setValue(-1., where = x > L/2)
# Viewer
viewer = None
if __name__ == '__main__':
viewer = Viewer(vars=dT, datamin=-1., datamax=1.)
viewer.plotMesh()
raw_input("...")
# Boussinesq equations
D = landa/ro0
eqX = (TransientTerm(var=xVelocity) + ConvectionTerm (var=xVelocity, 
coeff=velocity) == 0)
eqZ = (TransientTerm(var=zVelocity) + ConvectionTerm (var=zVelocity, 
coeff=velocity) + alpha*g*dT == 0)
eqT = (TransientTerm(var=dT) + ConvectionTerm (var=dT, coeff=velocity) == 
DiffusionTerm(var=dT, coeff=D))
eq = eqX & eqZ & eqT
# Solving Boussinesq equations
timeStepDuration = 1 * dL**2 / (2 * D)
steps = 50
sweeps = 5
for step in range(steps):
for sweep in range(sweeps):
eq.sweep(dt=timeStepDuration)
velocity[0] = xVelocity.arithmeticFaceValue
velocity[1] = zVelocity.arithmeticFaceValue
velocity[..., mesh.exteriorFaces.value] = 0.
if viewer is not None:
viewer.plot()
plt.pause(0.1)
raw_input("… ")


> On Aug 14, 2018, at 11:22 AM, fgendr01  wrote:
> 
> Hello,
> 
> I’m a PhD Student in La Rochelle University (France) and I’m working on 
> Boussinesq Approximation.
> I’m starting with fipy and I’d like to make a little algorithm to solve these 
> equations in 2D (x,z) :
> 
> In my problem T = T0 + dT.
> (ux, uz) is the velocity.
> 
> So, here is my algorithm :
> # -*- coding: utf-8 -*-
> from fipy import *
> import matplotlib.pyplot as plt
> # Parameter
> L = 1. 
> N = 50.
> dL = L/N
> alpha = 0.0002# Thermical dilatation
> landa = 0.6   # Thermical conductivity
> ro0 = 1023.   # Average volumic Mass
> g = 10.   # Gravity
> # Mesh
> mesh = Grid2D(nx=N, ny=N, dx=dL, dy=dL)
> # Variables
> dT = CellVariable(name = 'dT', mesh = mesh, value = 0.)
> xVelocity = FaceVariable(mesh=mesh, name='Xvelocity', value = 0., rank=1)
> zVelocity = FaceVariable(mesh=mesh, name='Zvelocity', value = 0., rank=1)
> # Init Condition
> x = mesh.cellCenters[0]
> dT.setValue(1.)
> dT.setValue(-1., where = x > L/2)
> # Viewer
> viewer = None
> if __name__ == '__main__':
>   viewer = Viewer(vars=dT, datamin=-1., datamax=1.)
>   viewer.plotMesh()
>   raw_input("...")
> # Boussinesq equations
> D = landa/ro0
> velocity = ((xVelocity), (zVelocity))
> eqX = (TransientTerm(var=xVelocity) + ConvectionTerm (var=xVelocity, 
> coeff=velocity) == 0)
> eqZ = (TransientTerm(var=zVelocity) + ConvectionTerm (var=zVelocity, 
> coeff=velocity) + alpha*g*dT == 0)
> eqT = (TransientTerm(var=dT) + ConvectionTerm (var=dT, coeff=velocity) == 
> -DiffusionTerm(var=dT, coeff=D))
> eq = eqX & eqZ & eqT
> # Solving Boussinesq equations
> timeStepDuration = 10 * dL**2 / (2 * D)
> steps = 50
> for step in range(steps):
>   eq.solve(dt=timeStepDuration)
>   if viewer is not None:
>   viewer.plot()
>   plt.pause(0.1)
> raw_input("… »)
> 
> My error : all the input arrays must have same number of dimensions
> 
> I’d like to obtain something like this :
> 
> 
> If someone can help me, I will be very happy.
> 
> Thanks a lot.
> 
> Fabien G.
> ___
> 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: Remeshing and code speedup

[Guyer, Jonathan E. Dr. (Fed)]

Understood. I think you will find that a 2000x2000 2D problem (assuming you 
have enough RAM) will not take anything like 7.5 h.

> On Jul 24, 2018, at 3:49 PM, Carsten Langrock  wrote:
> 
> I tried a few solvers for this 1D diffusion problem and it does indeed appear 
> that pySparse is faster than the rest. Sadly, faster doesn’t equate to fast … 
> about 4 seconds for a 2000 grid, 440 time steps nonlinear diffusion process 
> using a single sweep. For the second part, which opens the left boundary and 
> forces it to zero, it takes another 9.5 seconds when choosing 3 sweeps. And 
> that’s on a fast computer.
> 
> Thanks again for pointing out the use of different solvers.
> 
> Carsten
> 
> _
> Dipl.-Phys. Carsten Langrock, Ph.D.
> 
> Senior Research Scientist
> Edward L. Ginzton Laboratory, Rm. 202
> Stanford University
> 
> 348 Via Pueblo Mall
> 94305 Stanford, CA
> 
> Tel. (650) 723-0464
> Fax (650) 723-2666
> 
> Ginzton Lab Shipping Address:
> James and Anna Marie Spilker Engineering and Applied Sciences Building
> 04-040
> 348 Via Pueblo Mall
> 94305 Stanford, CA
> _____
> 
>> On Jul 24, 2018, at 6:11 AM, Guyer, Jonathan E. Dr. (Fed) 
>>  wrote:
>> 
>> FiPy still does not support remeshing. 
>> 
>> As Dario said, choice of solver can make a big difference. I've not used 
>> PyAMG much, but PySparse is dramatically faster than SciPy. PyTrilinos is 
>> slower than PySparse, but enables you to solve in parallel.
>> 
>> I've also found that 2D problems solve much better than the 1D performance 
>> would lead you to believe. There's just a lot of overhead in setting up the 
>> problem and the Python communication with the lower-level libraries.
>> 
>> On Jul 23, 2018, at 6:44 PM, Carsten Langrock  wrote:
>> 
>> Hi,
>> 
>> Thanks for the help with getting FiPy running under Linux! I am trying to 
>> re-create a 1D nonlinear diffusion problem for which we have C++ code that 
>> uses the implicit Thomas algorithm based on 
>> 
>> J. Weickert, B. Romerny, M. Viergever, "Efficient and Reliable Schemes
>> for Nonlinear Diffusion Filtering”, IEEE transactions on Image Processing, 
>> vol.7, N03, page 398, March 1998
>> 
>> I have been able to get results in FiPy that match this code very closely 
>> which was a great start. Our C++ code uses a fixed number of spatial points 
>> and a fixed time step, but re-meshes space to most efficiently use the size 
>> of the array; it increases the spatial step size by 2 whenever the 
>> concentration at a particular point reaches a set threshold. I tried 
>> implementing this in FiPy as well, but haven’t had much luck so far. I saw 
>> an old mailing-list entry from 2011 where a user was told that FiPy wasn’t 
>> meant to do remeshing. Is that still the case?
>> 
>> I’d imagine one would somehow need to update the Grid1D object with the new 
>> ‘dx’, but since the CellVariable that holds the solution was initialized 
>> with that mesh object, I am not sure that such a change would propagate in a 
>> sensible fashion. I think I know how to map the value of the CellVariable to 
>> account for the change in ‘dx’ by 
>> 
>> array_size = 2000
>> phi.value = numpy.concatenate((phi.value[1:array_size/2:2], 
>> numpy.zeros(1500)))
>> 
>> for the case when the initial variable holds 2000 spatial points. Maybe 
>> there’s a more elegant way, but I think this works in principle.
>> 
>> Another question would be execution speed. Right now, even when not plotting 
>> the intermediate solutions, it takes many seconds on a very powerful 
>> computer to run a simple diffusion problem. I am probably doing something 
>> really wrong. I wasn’t expecting the code to perform as well as the C++ 
>> code, but I had hoped to come within an order of magnitude. Are there ways 
>> to optimize the performance? Maybe select a particularly clever solver? If 
>> someone could point me into the right direction that’d be great. In the end, 
>> I would like to expand the code into 2D, but given the poor 1D performance, 
>> I don’t think that this would be feasible at this point.
>> 
>> Thanks,
>> Carsten
>> 
>> _
>> Dipl.-Phys. Carsten Langrock, Ph.D.
>> 
>> Senior Research Scientist
>> Edward L. Ginzton Laboratory, Rm. 202
>> Stanford University
>> 
>> 348 Via Pueblo Mall
>> 94305 Stanford, CA
>> 
>> Tel. (650) 723-0464
>> Fax (650) 723-2666
>> 
>> Ginzton Lab 

Re: FiPy Heat Transfer Solution

[Guyer, Jonathan E. Dr. (Fed)]

> On Jul 24, 2018, at 9:12 AM, Daniel Wheeler  wrote:
> 
> Jon, is that correct?

I honestly don't know


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

Re: Remeshing and code speedup

[Guyer, Jonathan E. Dr. (Fed)]

FiPy still does not support remeshing. 

As Dario said, choice of solver can make a big difference. I've not used PyAMG 
much, but PySparse is dramatically faster than SciPy. PyTrilinos is slower than 
PySparse, but enables you to solve in parallel.

I've also found that 2D problems solve much better than the 1D performance 
would lead you to believe. There's just a lot of overhead in setting up the 
problem and the Python communication with the lower-level libraries.

> On Jul 23, 2018, at 6:44 PM, Carsten Langrock  wrote:
> 
> Hi,
> 
> Thanks for the help with getting FiPy running under Linux! I am trying to 
> re-create a 1D nonlinear diffusion problem for which we have C++ code that 
> uses the implicit Thomas algorithm based on 
> 
> J. Weickert, B. Romerny, M. Viergever, "Efficient and Reliable Schemes
> for Nonlinear Diffusion Filtering”, IEEE transactions on Image Processing, 
> vol.7, N03, page 398, March 1998
> 
> I have been able to get results in FiPy that match this code very closely 
> which was a great start. Our C++ code uses a fixed number of spatial points 
> and a fixed time step, but re-meshes space to most efficiently use the size 
> of the array; it increases the spatial step size by 2 whenever the 
> concentration at a particular point reaches a set threshold. I tried 
> implementing this in FiPy as well, but haven’t had much luck so far. I saw an 
> old mailing-list entry from 2011 where a user was told that FiPy wasn’t meant 
> to do remeshing. Is that still the case?
> 
> I’d imagine one would somehow need to update the Grid1D object with the new 
> ‘dx’, but since the CellVariable that holds the solution was initialized with 
> that mesh object, I am not sure that such a change would propagate in a 
> sensible fashion. I think I know how to map the value of the CellVariable to 
> account for the change in ‘dx’ by 
> 
> array_size = 2000
> phi.value = numpy.concatenate((phi.value[1:array_size/2:2], 
> numpy.zeros(1500)))
> 
> for the case when the initial variable holds 2000 spatial points. Maybe 
> there’s a more elegant way, but I think this works in principle.
> 
> Another question would be execution speed. Right now, even when not plotting 
> the intermediate solutions, it takes many seconds on a very powerful computer 
> to run a simple diffusion problem. I am probably doing something really 
> wrong. I wasn’t expecting the code to perform as well as the C++ code, but I 
> had hoped to come within an order of magnitude. Are there ways to optimize 
> the performance? Maybe select a particularly clever solver? If someone could 
> point me into the right direction that’d be great. In the end, I would like 
> to expand the code into 2D, but given the poor 1D performance, I don’t think 
> that this would be feasible at this point.
> 
> Thanks,
> Carsten
> 
> _
> Dipl.-Phys. Carsten Langrock, Ph.D.
> 
> Senior Research Scientist
> Edward L. Ginzton Laboratory, Rm. 202
> Stanford University
> 
> 348 Via Pueblo Mall
> 94305 Stanford, CA
> 
> Tel. (650) 723-0464
> Fax (650) 723-2666
> 
> Ginzton Lab Shipping Address:
> James and Anna Marie Spilker Engineering and Applied Sciences Building
> 04-040
> 348 Via Pueblo Mall
> 94305 Stanford, CA
> _
> ___
> 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 on Linux

[Guyer, Jonathan E. Dr. (Fed)]

Augh. This much I can explain: I copied the installation from .travis.yml 
without thinking about it. `conda create` does not explicitly install fipy 
because the whole point of that file is to test the current git commit, which 
is done later in the recipe. Adding `fipy` to the `conda create` line should be 
sufficient.

I believe the gmsh issue is that the 
[gmsh-feedstock](https://github.com/guyer/gmsh-feedstock) recipe I wrote has a 
runtime dependency on gcc that isn't satisfied on Debian, but is on the Ubuntu 
image that TravisCI sets up. I'll not be able to look into this for at least 
three weeks. Ideally, the gcc dependency should not be necessary, but reckless 
usage of apt-get could probably resolve the issue. As I recall, attempting to 
run gmsh from the command line is more instructive than letting fipy do it.



> On Jul 20, 2018, at 1:28 PM, Keller, Trevor (Fed)  
> wrote:
> 
> Hi Carsten,
> 
> Unfortunately, I can confirm that the Conda-based process does not currently 
> work on
> Debian 9.
> 
> $ ./Miniconda3-latest-Linux-x86_64.sh
> $ cat /absolute/path/to/miniconda/etc/profile.d/conda.sh >> ~/.bashrc
> $ . ~/.bashrc
> $ conda update conda
> $ conda create --name fipy --channel guyer --channel conda-forge python=2.7 
> numpy scipy gmsh pysparse mpi4py matplotlib mayavi fipytrilinos weave
> $ conda activate fipy
> $ python
> Python 2.7.15 | packaged by conda-forge | (default, May  8 2018, 14:46:53) 
> [GCC 4.8.2 20140120 (Red Hat 4.8.2-15)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import fipy
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: No module named fipy
> >>>
> 
> I can partially work around this problem by hybridizing the Conda and GitHub 
> installation methods,
> i.e. let Conda install the prereqs, then install FiPy from source.
> $ conda activate fipy
> $ conda install -n fipy gmsh
> $ git clone https://github.com/usnistgov/fipy
> $ cd fipy
> $ python setup.py install
> $ python
> Python 2.7.15 | packaged by conda-forge | (default, May  8 2018, 14:46:53) 
> [GCC 4.8.2 20140120 (Red Hat 4.8.2-15)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from fipy import test
> >>> test()
> ...
> --
> Ran 347 tests in 4.113s
> 
> OK
> !!!
> Skipped 105 doctest examples because `gmsh` cannot be found on the $PATH
> Skipped 83 doctest examples because the `tvtk` package cannot be imported
> !!!
> >>>
> 
> The failure to recognize gmsh -- which is most definitely present on $PATH -- 
> is vexing.
> Thanks for bringing this to our attention.
> 
> Trevor
> From: fipy-boun...@nist.gov  on behalf of Carsten 
> Langrock 
> Sent: Thursday, July 19, 2018 9:20:54 PM
> To: FIPY
> Subject: FiPy on Linux
>  
> Hi,
> 
> Since the macOS install didn’t result in much, I tried it under Linux. No 
> luck, it’s actually even worse. I cannot import fipy without generating 
> errors. It appears to hang on
> 
> ‘Could not import any solver package’
> 
> I saw that some reported the same problem but I didn’t see a solution. SciPy 
> is installed, of course. This is following the recommended installation 
> modality using miniconda.
> 
> Carsten
> 
> _
> Dipl.-Phys. Carsten Langrock, Ph.D.
> 
> Senior Research Scientist
> Edward L. Ginzton Laboratory, Rm. 202
> Stanford University
> 
> 348 Via Pueblo Mall
> 94305 Stanford, CA
> 
> Tel. (650) 723-0464
> Fax (650) 723-2666
> 
> Ginzton Lab Shipping Address:
> James and Anna Marie Spilker Engineering and Applied Sciences Building
> 04-040
> 348 Via Pueblo Mall
> 94305 Stanford, CA
> _
> ___
> 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: Fresh installation ... fipy.test() and diffusion examples fail

[Guyer, Jonathan E. Dr. (Fed)]

Our most current notion of how to install is captured 
[here](https://github.com/usnistgov/fipy/blob/develop/.travis.yml)

In short, on Mac OS:

  conda create --name  --channel guyer --channel conda-forge 
python=2.7 fipy weave

and on linux:

  conda create --name  --channel guyer --channel conda-forge 
python=2.7 numpy scipy gmsh pysparse mpi4py matplotlib mayavi fipytrilinos weave


and then for both:

  source activate 
  pip install scikit-fmm


Windows installations are covered 
[here](https://github.com/usnistgov/fipy/blob/develop/appveyor.yml), but 
basically you should be able to do the same as on Mac.



> On Jul 20, 2018, at 10:21 AM, Carsten Langrock  wrote:
> 
> Ok, thanks for the information. I’ll try this again using python 2.7. 
> 
> _
> Dipl.-Phys. Carsten Langrock, Ph.D.
> 
> Senior Research Scientist
> Edward L. Ginzton Laboratory, Rm. 202
> Stanford University
> 
> 348 Via Pueblo Mall
> 94305 Stanford, CA
> 
> Tel. (650) 723-0464
> Fax (650) 723-2666
> 
> Ginzton Lab Shipping Address:
> Astro-Physics Building, Rm. 148
> 452 Lomita Mall
> 
> Ginzton Lab Freight Deliveries:
> 491 South Service Road
> _
> 
> 
>> On Jul 20, 2018 at 06:38,  wrote:
>> 
>> FiPy should be installed with Python 2.7. We are aware that the 
>> documentation doesn't say this right now; getting the installation working 
>> smoothly and ensuring that all of the documentation describes the process 
>> completely and accurately is a non-trivial task.
>> 
>> 
>> > On Jul 19, 2018, at 8:02 PM, Carsten Langrock  
>> > wrote:
>> > 
>> > Hi,
>> > 
>> > It’s been a while since I tried using the FiPy package. I followed the 
>> > installation directions and used miniconda to generate a Python 
>> > environment for FiPy. Running the fipy.test() function lists a large 
>> > number of not installed packages, some of which I was able to install 
>> > manually; not sure why packages tested by FiPy in this function aren’t 
>> > part of the vanilla install … Other packages like pysparse don’t seem to 
>> > want to installed possibly due to a conflict between Python 2 and 3; I am 
>> > using the Python 3.6 version of minconda. There are two references to 
>> > mpi4py in the test script. I installed mpi4py, but …
>> > 
>> > gist version not available
>> > mpi4py version 3.0.0
>> > mpi4py is not installed
>> > 
>> > Not sure what’s going on here and what the difference may be.
>> > 
>> > The test() function also crashes the Python interpreter.
>> > 
>> > ==
>> > ERROR: testFiPy (unittest.loader._FailedTest)
>> > --
>> > ImportError: Failed to import test module: testFiPy
>> > Traceback (most recent call last):
>> >   File 
>> > "/Users/langrock/miniconda3/envs/FiPyEnv/lib/python3.6/unittest/loader.py",
>> >  line 153, in loadTestsFromName
>> > module = __import__(module_name)
>> > ModuleNotFoundError: No module named ‘fipy.testFiPy'
>> > 
>> > Trying to run the first diffusion example
>> > 
>> > python examples/diffusion/mesh1D.py
>> > 
>> > gives the following error
>> > 
>> > Traceback (most recent call last):
>> >   File "examples/diffusion/mesh1D.py", line 794, in 
>> > exec(fipy.tests.doctestPlus._getScript())
>> >   File "", line 139
>> > the transient diffusion equation"
>> > ^
>> > SyntaxError: Missing parentheses in call to 'print'. Did you mean 
>> > print("The SciPy library is not available to test the solution to \
>> > the transient diffusion equation”)?
>> > 
>> > I am not familiar with restructured text and how such commented code is 
>> > supposed to be run using the ipy.tests.doctestPlus._getScript() function, 
>> > but there’s apparently some issue.
>> > 
>> > The second example fails differently, which seems to indicate a problem in 
>> > the call to splu()
>> > 
>> > python examples/diffusion/coupled.py
>> > 
>> > /Users/langrock/miniconda3/envs/FiPyEnv/lib/python3.6/site-packages/fipy/viewers/matplotlibViewer/__init__.py:113:
>> >  UserWarning: Matplotlib1DViewer efficiency is improved by setting the 
>> > 'datamax' and 'datamin' keys
>> >   return Matplotlib1DViewer(vars=vars, title=title, axes=axes, **kwlimits)
>> > Traceback (most recent call last):
>> >   File "examples/diffusion/coupled.py", line 153, in 
>> > exec(fipy.tests.doctestPlus._getScript())
>> >   File "", line 66, in 
>> >   File 
>> > "/Users/langrock/miniconda3/envs/FiPyEnv/lib/python3.6/site-packages/fipy/terms/term.py",
>> >  line 254, in sweep
>> > solver._solve()
>> >   File 
>> > "/Users/langrock/miniconda3/envs/FiPyEnv/lib/python3.6/site-packages/fipy/solvers/scipy/scipySolver.py",
>> >  line 61, in _solve
>> > self.var[:] = numerix.reshape(self._solve_(self.matrix, 
>> > self.var.ravel(), numerix.array(self.RHSvector)), self.var.shape)   
>> >   File 
>> > 

Re: Fresh installation ... fipy.test() and diffusion examples fail

[Guyer, Jonathan E. Dr. (Fed)]

FiPy should be installed with Python 2.7. We are aware that the documentation 
doesn't say this right now; getting the installation working smoothly and 
ensuring that all of the documentation describes the process completely and 
accurately is a non-trivial task.


> On Jul 19, 2018, at 8:02 PM, Carsten Langrock  wrote:
> 
> Hi,
> 
> It’s been a while since I tried using the FiPy package. I followed the 
> installation directions and used miniconda to generate a Python environment 
> for FiPy. Running the fipy.test() function lists a large number of not 
> installed packages, some of which I was able to install manually; not sure 
> why packages tested by FiPy in this function aren’t part of the vanilla 
> install … Other packages like pysparse don’t seem to want to installed 
> possibly due to a conflict between Python 2 and 3; I am using the Python 3.6 
> version of minconda. There are two references to mpi4py in the test script. I 
> installed mpi4py, but …
> 
> gist version not available
> mpi4py version 3.0.0
> mpi4py is not installed
> 
> Not sure what’s going on here and what the difference may be.
> 
> The test() function also crashes the Python interpreter.
> 
> ==
> ERROR: testFiPy (unittest.loader._FailedTest)
> --
> ImportError: Failed to import test module: testFiPy
> Traceback (most recent call last):
>   File 
> "/Users/langrock/miniconda3/envs/FiPyEnv/lib/python3.6/unittest/loader.py", 
> line 153, in loadTestsFromName
> module = __import__(module_name)
> ModuleNotFoundError: No module named ‘fipy.testFiPy'
> 
> Trying to run the first diffusion example
> 
> python examples/diffusion/mesh1D.py
> 
> gives the following error
> 
> Traceback (most recent call last):
>   File "examples/diffusion/mesh1D.py", line 794, in 
> exec(fipy.tests.doctestPlus._getScript())
>   File "", line 139
> the transient diffusion equation"
> ^
> SyntaxError: Missing parentheses in call to 'print'. Did you mean print("The 
> SciPy library is not available to test the solution to \
> the transient diffusion equation”)?
> 
> I am not familiar with restructured text and how such commented code is 
> supposed to be run using the ipy.tests.doctestPlus._getScript() function, but 
> there’s apparently some issue.
> 
> The second example fails differently, which seems to indicate a problem in 
> the call to splu()
> 
> python examples/diffusion/coupled.py
> 
> /Users/langrock/miniconda3/envs/FiPyEnv/lib/python3.6/site-packages/fipy/viewers/matplotlibViewer/__init__.py:113:
>  UserWarning: Matplotlib1DViewer efficiency is improved by setting the 
> 'datamax' and 'datamin' keys
>   return Matplotlib1DViewer(vars=vars, title=title, axes=axes, **kwlimits)
> Traceback (most recent call last):
>   File "examples/diffusion/coupled.py", line 153, in 
> exec(fipy.tests.doctestPlus._getScript())
>   File "", line 66, in 
>   File 
> "/Users/langrock/miniconda3/envs/FiPyEnv/lib/python3.6/site-packages/fipy/terms/term.py",
>  line 254, in sweep
> solver._solve()
>   File 
> "/Users/langrock/miniconda3/envs/FiPyEnv/lib/python3.6/site-packages/fipy/solvers/scipy/scipySolver.py",
>  line 61, in _solve
> self.var[:] = numerix.reshape(self._solve_(self.matrix, self.var.ravel(), 
> numerix.array(self.RHSvector)), self.var.shape)   
>   File 
> "/Users/langrock/miniconda3/envs/FiPyEnv/lib/python3.6/site-packages/fipy/solvers/scipy/linearLUSolver.py",
>  line 64, in _solve_
> permc_spec=3)
> TypeError: splu() got an unexpected keyword argument ‘drop_tol'
> 
> 
> Anyhow, it’d be nice to at least get the simplest examples to work on my 
> machine (macOS 10.13.6). Even following the mesh1D.py example by hand 
> resulted in errors at 
> 
> eqX.solve(var=phi, dt=timeStepDuration)
> 
> The error was the same as the one above referencing the splu() call with an 
> unexpected keyword argument ‘drop_tol’.
> 
> Thanks,
> Carsten
> 
> _
> Dipl.-Phys. Carsten Langrock, Ph.D.
> 
> Senior Research Scientist
> Edward L. Ginzton Laboratory, Rm. 202
> Stanford University
> 
> 348 Via Pueblo Mall
> 94305 Stanford, CA
> 
> Tel. (650) 723-0464
> Fax (650) 723-2666
> 
> Ginzton Lab Shipping Address:
> James and Anna Marie Spilker Engineering and Applied Sciences Building
> 04-040
> 348 Via Pueblo Mall
> 94305 Stanford, CA
> _
> ___
> 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: how to compute the area of the solid material in examples.phase.anisotropy?

[Guyer, Jonathan E. Dr. (Fed)]

`phase.cellVolumeAverage * mesh.cellVolumes.sum()` ought to do it


From: fipy-boun...@nist.gov  on behalf of Drew Davidson 

Sent: Thursday, July 19, 2018 11:57:37 AM
To: FIPY
Subject: how to compute the area of the solid material in   
examples.phase.anisotropy?

Hello,

Would anyone please give the FiPy code which computes the area of the 
solidified material in examples.phase.anisotropy?

Searching for --area-- in the Mailing List Archives returns a rather broad 
result set.

Thanks

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

Re: Can Gmsh2D read a 1D gmsh mesh?

[Guyer, Jonathan E. Dr. (Fed)]

Thanks for the tip

> On Jul 13, 2018, at 10:33 PM, Drew Davidson  wrote:
> 
> Hello,
> 
> It seems possible to generate a parameterized 1D mesh using gmsh within a 
> python script, and then generate the corresponding 1D FiPy mesh in that same 
> python script:
> 
> 1) Use pygmsh in a python script to construct a parameterized 1D (gmsh) mesh.
> 
> 2) From that 1D mesh, construct a list of dx's
> 
> 3) Follow https://www.mail-archive.com/fipy@nist.gov/msg01650.html and create 
> a 1D FiPy mesh from a list of dx's.
> 
> It was pure luck to have found the mailing list message in (3).
> 
> I did not see how to get the Physical Groups data from the pygmsh mesh into 
> the FiPy mesh.
> 
> Thanks
> 
> 
> 
> On Thu, Jul 12, 2018 at 3:26 PM Guyer, Jonathan E. Dr. (Fed) 
>  wrote:
> No, FiPy doesn't presently have any ability to read 1D meshes.
> 
> I do have some experimental code that supports this, but it needs a lot of 
> work. I have no prognosis for when this will be made public.
> 
> - Jon
> 
> > On Jul 12, 2018, at 1:21 PM, Drew Davidson  wrote:
> > 
> > Hello,
> > 
> > Can Gmsh2D read a 1D gmsh mesh?
> > 
> > I have tried a similar script to the FiPy diffusion example circle.py:
> > 
> > SCRIPT BEGINS
> > import fipy as fp
> > from IPython import embed
> > import sys
> > 
> > #I created this gmsh .geo file in gmsh GUI, then copied and pasted here; I 
> > cannot see a syntax error if it exists???
> > 
> > geo="""
> > L_Sample=%(L_Sample)g;
> > L_Substrate=%(L_Substrate)g;
> > cellSize=%(cellSize)g;
> > Point(1) = {0, 0, 0, cellSize};
> > Point(2) = {L_Substrate, 0, 0, cellSize};
> > Point(3) = {L_Substrate+L_Sample, 0, 0, cellSize};
> > Line(1) = {1, 2};
> > Line(2) = {2, 3};
> > Physical Point("SubstrateEnd") = {1};
> > Physical Point("SampleEnd") = {3};
> > Physical Point("ThermalContact") = {2};
> > Physical Line("Substrate") = {1};
> > Physical Line("Sample") = {2};
> > """ % locals()
> > 
> > #I am not having success with:
> > mesh = fp.Gmsh2D(geo,coordDimensions=1) #TODO throwing error about there 
> > being no cells; is it a problem that mesh is 1D and Gmsh2D is called 2D?
> > mesh = fp.Gmsh2D(geo) #TODO throwing error about there being no cells
> > 
> > #then I went into gmsh GUI and saved to .msh, but still no luck:
> > mesh = fp.Gmsh2D('OneDimensionalSampleAndSubstrate.msh') #TODO throwing 
> > error about there being no cells
> > mesh = fp.Gmsh2D('OneDimensionalSampleAndSubstrate.msh',coordDimensions=1) 
> > #TODO throwing error about there being no cells
> > SCRIPT ENDS
> > 
> > 
> > If coordDimensions=1 is unsupported or meaningless, it would be great if 
> > FiPy printed a message saying so.
> > 
> > I believe my FiPy installation is OK and was downloaded from github 
> > 6/30/2018 (fipy-develop). I can run circle.py, although I have never gotten 
> > it to plot the mesh. I can run anisotropy.py from diffusivity examples. 
> > Nearly all fipy tests pass (setup.py).  Can you please check if Gmsh2D is 
> > capable of reading a 1D gmsh mesh? Or is there another FiPy class which can 
> > do it, and how?
> > 
> > gmsh –version returns 3.0.6.  Installation is system-wide via download 
> > method in Ubuntu 16.04.
> > 
> > If I cannot read in a parameterized 1D gmsh mesh using FiPy functionality, 
> > I am at a loss as to how to have a single Python script that allows me to 
> > set cellSize, L_Sample, and L_Substrate, produce a mesh, and efficiently 
> > conduct a parameter study with FiPy. Gmsh is desirable because I want to go 
> > to a more complicated nonuniform/graded mesh, and would rather not write 
> > code to make a mesh myself.
> > 
> > Thanks.
> > 
> > 
> > ___
> > 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 ]
> ___
> 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: Logistic ODE as a source term

[Guyer, Jonathan E. Dr. (Fed)]

Hello Derek -

Thanks for your question.

> So does this imply that the correct way to implement this source term would 
> be:
> 
>  ImplicitSourceTerm(coeff = r_H * C_A * A * (1 - H_bar()/K_H) - delta_H - 
> delta_D * S)

Yes

> With H_bar() being a function:
> 
> # Set up the summing of HSCs
> def H_bar():
> return H.cellVolumeAverage * mesh.cellVolumes.sum()

> 
> 
> Am I incorrect in manually computing H_bar() at every timestep and then using 
> it as the source term coefficient? 

There's no reason to write a function here. Just define

H_bar = H.cellVolumeAverage * mesh.cellVolumes.sum()

and then use

(1 - H_bar / K_H)

in your source. FiPy will take care of updating the value as needed.


> Also, will there be any problems with A and S also being CellVariables in 
> this coupled PDE system?

No

> For the Convection term:
> 
> And as another question, for the convection term, is it appropriate to have 
> it as:
> 
> ConvectionTerm(coeff = v_A + C_phi + Phi() + S.faceGrad)

Do you mean

ConvectionTerm(coeff = v_A + C_phi * Phi() * S.faceGrad)

?

ConvectionTerm represents $\nabla\cdot(\vec{u} H)$, but your expression is just 
$\vec{u} \cdot \nabla H$. You're missing $H \nabla\cdot\vec{u}$. Specifically, 
you have a source 

   ImplicitSourceTerm(coeff=C_phi * Phi() * S.faceGrad.divergence, var=H)


> As in the source term, will there be issues with having Phi() as a function 
> which changes at every timestep? 

Shouldn't be, but it depends how you define it. Basically, the thing to 
remember is that the function Phi() will not be called at each time step. The 
return value of the function will be evaluated at each time step. If the return 
value depends on your solution variable, then it will update. If the return 
value depends on the *value* of the solution variable, then it will not update. 

You're generally better off just writing a variable expression, e.g.,

Phi = H * A * S + ...

than defining a function. 


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

Re: Flux BC Dependent on Potential

[Guyer, Jonathan E. Dr. (Fed)]

David -

The problem is here:

   diffCoeff=Variable(value=1.)
   diffCoeff.constrain(0., mesh.facesLeft)

It doesn't mean anything to constrain a Variable at particular faces. A 
Variable doesn't exist on a mesh; it's just a value.

You can either do 

   diffCoeff=CellVariable(mesh=mesh, value=1.)
   diffCoeff.constrain(0., mesh.facesLeft)

or

   diffCoeff=Variable(value=1.)

and leave off the constraint.



Taking the divergence 51 faces to get 50 cells is not a problem.


DiffusionTerm is declared right here on the page you linked:

https://www.ctcms.nist.gov/fipy/fipy/generated/fipy.terms.html#fipy.terms.diffusionTerm.DiffusionTerm

DiffusionTerm is an implicit term, which is what you usually want. 
ExplicitDiffusionTerm is generally not what you want.


> On Jun 4, 2018, at 11:13 PM, Ollodart, David Bernd  
> wrote:
> 
> Hello,
> 
> I have a reaction-diffusion equation which has a flux boundary condition 
> dependent on the potential value at the boundary. I have seen in 
> examples.diffusion.mesh1d how to set the boundary conditions to a constant or 
> function of independent variables, but trying to insert the dependent 
> variable, or its face value (evaluated at some face(s)) directly into 
> .constrain does not work. I have seen at 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mail-archive.com%2Ffipy%40nist.gov%2Fmsg00389.html=02%7C01%7Cjonathan.guyer%40nist.gov%7Cb48df7e9f52d4b681f4608d5ca9277f3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636637652788127952=5f05NC56AzhaVB%2BGKg9gncSQTlDSsUQugUfNQzYNRDs%3D=0
>  a question exactly on this topic but it uses FixedFlux which is now 
> deprecated: https://www.ctcms.nist.gov/fipy/documentation/USAGE.html. But I 
> have problems trying to implement the new methods suggested under "Applying 
> fixed flux boundary conditions". By the way,!
  there seems to be a typo; it should read ExplicitDiffusionTerm(diffCoeff) 
rather than DiffusionCoeff(diffCoeff), there being no DiffusionCoeff() in the 
fipy.terms package: 
https://www.ctcms.nist.gov/fipy/fipy/generated/fipy.terms.html. 
> 
> I am first trying to use a constant external flux in the new method, which 
> could be achieved by potential.faceGrad.constrain(1., mesh.facesLeft), then 
> extend it to a potential-dependent flux. I have modified 
> examples.diffusion.mesh1d as below. I define the exterior flux on the whole 
> interior mesh, because the product with mesh.facesLeft makes it only non-zero 
> on the left face. The script is:
> ---
> from fipy import *
> from scipy.special import erf
> 
> #defining mesh of independent variables
> nx = 50
> dx = 1.
> mesh = Grid1D(nx=nx, dx=dx)
> timeStepDuration = 0.9*dx**2/(2*1)
> steps = 10
> x = mesh.cellCenters[0]
> t = timeStepDuration * steps
> 
> #setting parameter values
> diffCoeff=Variable(value=1.)
> diffCoeff.constrain(0., mesh.facesLeft)
> 
> #defining solution variable and known analytical
> phi = CellVariable(name="solution variable",
>mesh=mesh,
>value=0.)
> 
> #defining boundary conditions
> phi.constrain(1.,mesh.facesRight)
> exteriorFlux = FaceVariable(name="fixed flux",
>mesh=mesh,
>value=1.,
>rank=1)
> 
> #defining governing equations (might be matrix or vector valued for multiple 
> dependent variables)
> eqn = TransientTerm() == ExplicitDiffusionTerm(coeff=diffCoeff) + 
> (mesh.facesLeft * exteriorFlux).divergence
> 
> #defining the viewer
> viewer = Viewer(vars=phi,
>datamin=0.,datamax=1.)
> 
> #iterating through solution
> for step in range(steps):
> eqn.solve(var=phi,dt=timeStepDuration)
>viewer.plot()
> 
> raw_input("Diffusion profile. Press  to proceed...")
> --
> However, this throws an IndexError: too many indices for array. If i print 
> the product of exteriorFlux and mesh.facesLeft, it is an array of 51 
> elements, the leftmost being 1, the others being 0, which is 1 greater than 
> the size of the array found from mesh.cellCenters which is what the 
> CellVariable is defined on. This error results if one specifies flux on one 
> or both sides of the mesh, the latter being the example provided. Since there 
> is 1 more face than there are cells, this result might be expected for 
> exteriorFlux, but then which mesh should be chosen? Trying to define a 
> different mesh throws an error for the product mesh.facesLeft * exteriorFlux.
> 
> Thank you,
> 
> David Ollodart
> ___
> 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 nonlinear coupled reaction diffusion equations (reaction networks) in FiPy

[Guyer, Jonathan E. Dr. (Fed)]

> On Apr 5, 2018, at 6:02 PM, Alokendra  wrote:
> 
> I am not so sure about the reaction 
> terms which can be coupled nonlinear functions. Do I need to use some 
> variation of `ImplicitSource` term?

Yes, these terms are appropriate for ImplicitSourceTerms, e.g., I would 
probably write $(k_fC_AC_B-k_rC_C)$ as

  ImplicitSourceTerm(coeff=k_f * C_A, var=C_B) - ImplicitSourceTerm(coeff=k_r, 
var=C_C)

The first term could also be written

  ImplicitSourceTerm(coeff=k_f * C_B, var=C_A)

but that would result in less coupling between the equations, which would 
generally slow convergence. The first form might not be stable, though, so I 
would have to experiment if I was doing this.

> Also what is the most efficient way to get Fipy read information such as 
> rate constants, diffusion coefficients and drift diffusion coefficients 
> for many such species? Because of the nonlinearity in the reaction term 
> it cannot be vectorized in straightforward manner.

That depends on the form the coefficients take wherever you're getting them 
from. 

I would argue that one of the biggest advantages of FiPy over some other PDE 
solvers is that you define your problem with the Turing-complete Python 
programming language and not some dedicated scripting language or batch input 
file. You can do anything that Python can do to read and parse files.
___
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
  [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]

Re: Units within sweeping a system

[Guyer, Jonathan E. Dr. (Fed)]

Units are not as well integrated in FiPy as I would like. The best I can offer 
is that you declare dimensional parameters and then combine them into 
dimensionless coefficients before sending them off to the solvers. Not very 
satisfactory, I'll admin.

Even if they did work, you'll find that your equation is not balanced. Neither 
TransientTerm nor DiffusionTerm has any intrinsic units unless you assign them. 
In the case of TransientTerm, you do this with a dimensional coeff. For the 
DiffusionTerm, you would need to declare a dimensional mesh, e.g., `mesh = 
fp.Grid1D(nx=..., dx="1 mum")`, but that seems to be broken right now.

> On Mar 27, 2018, at 5:31 AM, Kevin Blondino  wrote:
> 
> Hi,
> 
> I apologize if I am asking too many somewhat basic questions, as I would 
> still consider myself new to using mathematical software to this degree.
> 
> I wish to use units in my nonlinear coupled system. So far, I have gotten the 
> units to work in all my algebraic calculations; however, when I try solving, 
> FiPy claims it cannot sweep with units, because it can't convert to "floats." 
> The exact error is the following:
> 
> TypeError, Not possible to convert a PhysicalField with dimension to float
> 
> 
> One of the equations in the system is as such, with density and diffusivity 
> having units of m^-3 and m^2/s, respectively.
> 
> density.equation = TransientTerm(coeff=1.0, var=density)\
>   == DiffusionTerm(coeff=Diffusivity, var=density)
> 
> If I tack on ".numericValue" on to the end of the coefficient terms, a 
> different error is raised. It is also important to note that my system is 1 
> dimensional and without any use of tensors.
> 
> IndexError: diffusion coefficient tensor is not an appropriate shape for this 
> mesh 
> 
> Do I need to fully-remove any form of units in both the coefficient and/or 
> the var of the Transient/Diffusion terms before sweeping?
> 
> 
> Thanks,
> Kevin
> ___
> 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: Viewer Feature Request / Clarification

[Guyer, Jonathan E. Dr. (Fed)]

Your solution is fine; it just doesn't generalize.

Consider that we make no promise that mesh.x is even in ascending order. In my 
view, it's better to let us worry about tying together geometry, topology, and 
data, and you worry about presentation via subclassing. If that model only 
makes sense to me, I can learn to live with that.

What's illustrated in fipy.viewers.matplotlibViewer.test, btw?

> On Mar 22, 2018, at 7:37 AM, Daniel Lewis <lewi...@rpi.edu> wrote:
> 
> Hi John, et al.
> 
> I'm sorry in advance if I'm missing the point.  I think FiPy does a
> nice job of giving the user tools to do visualizations.  With respect
> to multiple viewers, this is what I was thinking of:
> 
> https://www.ctcms.nist.gov/fipy/fipy/generated/fipy.viewers.matplotlibV
> iewer.html#module-fipy.viewers.matplotlibViewer.test
> 
> Admittedly the design of FiPy and the intended usage example above does
> everything (and more) that I do in my snippet here:
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fkablondino%2F0cc44c3ea4e807b8e2088adbe40ef142=02%7C01%7Cjonathan.guyer%40nist.gov%7C3df2f9c1cf9b4f398cd808d58fe96a9c%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636573155048426975=2LrLtsiR59XcmMDu1zUvma4Yd261RGV6HZCJJ8JZrNE%3D=0
> 
> Maybe my approach isn't general enough?
> 
> Thanks again for FiPy.
> 
> Best,
> Dan
> 
> -- 
> Dan Lewis
> Materials Science and Engineering
> Materials Research Center 110
> Rensselaer Polytechnic Institute
> 110 8th Street
> Troy, NY 12180
> lewi...@rpi.edu
> 518-276-2297
> 
> On Tue, 2018-03-20 at 13:21 +, Guyer, Jonathan E. Dr. (Fed) wrote:
>> I must confess that this answer makes me sad. FiPy is object oriented
>> precisely so that you don't need to do this. The intended design is
>> that you subclass Matplotlib1DViewer to override the behavior you
>> want. There are two places you can do this:
>> 
>> * In Matplotlib1DViewer.__init__(), around 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fusnistg=02%7C01%7Cjonathan.guyer%40nist.gov%7C3df2f9c1cf9b4f398cd808d58fe96a9c%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636573155048426975=KPe4Bm%2BJ8iAwsSIRq%2BGsZPHZvU7F%2F51%2BaPA4t8Vff0Y%3D=0
>> ov/fipy/blob/71d82e1cc7b2c4e7c1c996d038fd8542d7e4c5a1/fipy/viewers/ma
>> tplotlibViewer/matplotlib1DViewer.py#L82 and following, add a
>> `color=` argument to the creation of the lines.
>> 
>> * In Matplotlib1DViewer._plot(), after 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fusnistgov%2Ff=02%7C01%7Cjonathan.guyer%40nist.gov%7C3df2f9c1cf9b4f398cd808d58fe96a9c%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636573155048426975=sKW13ir85JXFTmSaNkBDWHBN9I1Z%2FghRefxBuvHrlaE%3D=0
>> ipy/blob/71d82e1cc7b2c4e7c1c996d038fd8542d7e4c5a1/fipy/viewers/matplo
>> tlibViewer/matplotlib1DViewer.py#L145, add a `line[0].set_color()`
>> call.
>> 
>> In addition to subclassing for your own purposes, a pull request that
>> adds this capability to Matplotlib1DViewer would be most welcome.
>> 
>> P.S. I think Dan Lewis is thinking of the custom viewers in https://w
>> ww.ctcms.nist.gov/fipy/examples/phase/generated/examples.phase.anisot
>> ropy.html and https://www.ctcms.nist.gov/fipy/examples/phase/generate
>> d/examples.phase.polyxtal.html. Neither does the specific
>> customization you are looking for, but they illustrate how
>> subclassing a Viewer class is intended to work.
>> 
>> - Jon
>> 
>>> On Mar 19, 2018, at 12:48 PM, Michael J. Waters <waters.mike.j@gmai
>>> l.com> wrote:
>>> 
>>> Hi Kevin,
>>> 
>>> If you are using the Matplotlib Viewers, you could just skip the
>>> Viewers and use Matplotlib directly.  it's not hard to simply setup
>>> subplots using Matplotlib and it should be easy to get them to
>>> update the figure at each time step. 
>>> Best,
>>> 
>>> -Mike
>>> 
>>> 
>>> On 3/19/18 11:35 AM, Kevin Blondino wrote:
>>>> Hi,
>>>> 
>>>> My problem is one-dimensional. When plotting, I wish to have
>>>> side-by-side plots of separate cell variables. The color of the
>>>> lines default to a color scheme, i.e. the first line of each
>>>> subplot is blue, etc. I wish to have the viewer allow me to
>>>> choose the color of the line. Does this already exist? Or would I
>>>> have to export it as a TSV and plot it under my own accord? I
>>>> scoured the documentation and archive with no avail.
>>>> 
>>>> Thanks,
>>>> Kevin
>>>> 
&

Re: Viewer Feature Request / Clarification

[Guyer, Jonathan E. Dr. (Fed)]

No worries. Dan Wheeler is guilty of the same misconduct.

> On Mar 20, 2018, at 9:47 AM, Michael J. Waters <waters.mik...@gmail.com> 
> wrote:
> 
> Hi Jonathan,
> 
> Sorry to disappoint you. 
> Kevin, 
> If you have time, what Jonathon said is much better. Code contribution is 
> very important to open source projects!
> 
> Best,
> 
> -Mike
> 
> On 3/20/18 8:21 AM, Guyer, Jonathan E. Dr. (Fed) wrote:
>> I must confess that this answer makes me sad. FiPy is object oriented 
>> precisely so that you don't need to do this. The intended design is that you 
>> subclass Matplotlib1DViewer to override the behavior you want. There are two 
>> places you can do this:
>> 
>> * In Matplotlib1DViewer.__init__(), around 
>> https://github.com/usnistgov/fipy/blob/71d82e1cc7b2c4e7c1c996d038fd8542d7e4c5a1/fipy/viewers/matplotlibViewer/matplotlib1DViewer.py#L82
>>  and following, add a `color=` argument to the creation of the lines.
>> 
>> * In Matplotlib1DViewer._plot(), after 
>> https://github.com/usnistgov/fipy/blob/71d82e1cc7b2c4e7c1c996d038fd8542d7e4c5a1/fipy/viewers/matplotlibViewer/matplotlib1DViewer.py#L145
>> , add a `line[0].set_color()` call.
>> 
>> In addition to subclassing for your own purposes, a pull request that adds 
>> this capability to Matplotlib1DViewer would be most welcome.
>> 
>> P.S. I think Dan Lewis is thinking of the custom viewers in 
>> https://www.ctcms.nist.gov/fipy/examples/phase/generated/examples.phase.anisotropy.html
>>  and 
>> https://www.ctcms.nist.gov/fipy/examples/phase/generated/examples.phase.polyxtal.html
>> . Neither does the specific customization you are looking for, but they 
>> illustrate how subclassing a Viewer class is intended to work.
>> 
>> - Jon
>> 
>> 
>>> On Mar 19, 2018, at 12:48 PM, Michael J. Waters <waters.mik...@gmail.com>
>>>  wrote:
>>> 
>>> Hi Kevin,
>>> 
>>> If you are using the Matplotlib Viewers, you could just skip the Viewers 
>>> and use Matplotlib directly.  it's not hard to simply setup subplots using 
>>> Matplotlib and it should be easy to get them to update the figure at each 
>>> time step. 
>>> Best,
>>> 
>>> -Mike
>>> 
>>> 
>>> On 3/19/18 11:35 AM, Kevin Blondino wrote:
>>> 
>>>> Hi,
>>>> 
>>>> My problem is one-dimensional. When plotting, I wish to have side-by-side 
>>>> plots of separate cell variables. The color of the lines default to a 
>>>> color scheme, i.e. the first line of each subplot is blue, etc. I wish to 
>>>> have the viewer allow me to choose the color of the line. Does this 
>>>> already exist? Or would I have to export it as a TSV and plot it under my 
>>>> own accord? I scoured the documentation and archive with no avail.
>>>> 
>>>> Thanks,
>>>> Kevin
>>>> 
>>>> 
>>>> ___
>>>> 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
>>>  ]
>>> 
>> 
>> ___
>> 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 ]


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

Re: Viewer Feature Request / Clarification

[Guyer, Jonathan E. Dr. (Fed)]

I must confess that this answer makes me sad. FiPy is object oriented precisely 
so that you don't need to do this. The intended design is that you subclass 
Matplotlib1DViewer to override the behavior you want. There are two places you 
can do this:

* In Matplotlib1DViewer.__init__(), around 
https://github.com/usnistgov/fipy/blob/71d82e1cc7b2c4e7c1c996d038fd8542d7e4c5a1/fipy/viewers/matplotlibViewer/matplotlib1DViewer.py#L82
 and following, add a `color=` argument to the creation of the lines.

* In Matplotlib1DViewer._plot(), after 
https://github.com/usnistgov/fipy/blob/71d82e1cc7b2c4e7c1c996d038fd8542d7e4c5a1/fipy/viewers/matplotlibViewer/matplotlib1DViewer.py#L145,
 add a `line[0].set_color()` call.

In addition to subclassing for your own purposes, a pull request that adds this 
capability to Matplotlib1DViewer would be most welcome.

P.S. I think Dan Lewis is thinking of the custom viewers in 
https://www.ctcms.nist.gov/fipy/examples/phase/generated/examples.phase.anisotropy.html
 and 
https://www.ctcms.nist.gov/fipy/examples/phase/generated/examples.phase.polyxtal.html.
 Neither does the specific customization you are looking for, but they 
illustrate how subclassing a Viewer class is intended to work.

- Jon

> On Mar 19, 2018, at 12:48 PM, Michael J. Waters  
> wrote:
> 
> Hi Kevin,
> 
> If you are using the Matplotlib Viewers, you could just skip the Viewers and 
> use Matplotlib directly.  it's not hard to simply setup subplots using 
> Matplotlib and it should be easy to get them to update the figure at each 
> time step. 
> Best,
> 
> -Mike
> 
> 
> On 3/19/18 11:35 AM, Kevin Blondino wrote:
>> Hi,
>> 
>> My problem is one-dimensional. When plotting, I wish to have side-by-side 
>> plots of separate cell variables. The color of the lines default to a color 
>> scheme, i.e. the first line of each subplot is blue, etc. I wish to have the 
>> viewer allow me to choose the color of the line. Does this already exist? Or 
>> would I have to export it as a TSV and plot it under my own accord? I 
>> scoured the documentation and archive with no avail.
>> 
>> Thanks,
>> Kevin
>> 
>> 
>> ___
>> 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 ]


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

Re: Using ModularVariable in a mesh generated by gmsh

[Guyer, Jonathan E. Dr. (Fed)]

It is not presently possible to solve the grain impingement problem on a mesh 
that is not one of FiPy's predefined grids.

I don't believe it's hard to fix, but I needed to puzzle out why _meshSpacing 
was used at all (that bit of code is 14 years old). I now understand what it's 
doing, and I don't think it's hard, but it's also not something I can instantly 
fix.

https://github.com/usnistgov/fipy/issues/554


> On Feb 7, 2018, at 3:44 PM, Sachin Kurian <sach...@vt.edu> wrote:
> 
> In FiPy, it is possible to solve the common governing equations in a 
> non-standard geometry and mesh that is imported from gmsh. FiPy also solves 
> the coupled phase field (CellVariable) and orientation field 
> (ModularVariable) equations on a standard mesh. But defining a 
> ModularVariable on non-standard mesh leads to an error. 
> So, in its current setup, is it possible to solve the grain impingement 
> problem in a circular domain with triangular meshes using FiPy?
> Or is there any other way than using gmsh to get FiPy solve the grain 
> impingement problem in a non-standard geometry?
> 
> 
> On Wed, Feb 7, 2018 at 2:34 PM, Guyer, Jonathan E. Dr. (Fed) 
> <jonathan.gu...@nist.gov> wrote:
> SkewedGrid2D is a defined thing in FiPy.
> 
> GmshGrid2D and GmshGrid3D have a _meshSpacing property defined, but making a 
> generic periodic mesh with Gmsh will not induce this.
> 
> 
> > On Feb 7, 2018, at 12:07 PM, Sachin Kurian <sach...@vt.edu> wrote:
> >
> > Thank you.
> > I've tried using quad meshes from gmsh (I suppose this is what you meant by 
> > skew grids), but the same error shows up. So, the problem is that 
> > '_meshSpacing' is not an attribute for 'Gmsh2D' mesh if I define a 
> > ModularVariable on that mesh.
> >
> > On Wed, Feb 7, 2018 at 11:49 AM, Guyer, Jonathan E. Dr. (Fed) 
> > <jonathan.gu...@nist.gov> wrote:
> > _meshSpacing is only implemented for (square (including skew)) grids and 
> > only used by the _ModCellGradVariable. It's apparently been like that since 
> > before FiPy was FiPy, 14 years ago.
> >
> > I'll need to think about this more deeply to understand why normalizing by 
> > grid spacing even makes sense, much less what the answer should be for a 
> > general mesh.
> >
> >
> > > On Feb 6, 2018, at 7:17 PM, Sachin Kurian <sach...@vt.edu> wrote:
> > >
> > > Hi everyone,
> > >
> > > I've just started using FiPy. I'm particularely interested in the phase 
> > > field problems. I tried the examples of solidification and grain 
> > > impingement given in the documentation. What I intend to do is to use a 
> > > non-rectangular domain with triangular mesh for the problem. After 
> > > importing the unstructured mesh generated by gmsh, I assigned a 
> > > ModularVariable (theta) to the cells (Similar to the grain impingement 
> > > examples). Unfortunately, assigning a ModularVariable to the Gmsh2D() 
> > > mesh throws an attribute error:'Gmsh2D' object has no attribute 
> > > '_meshSpacing'  when I use theta.grad.mag command or try solving the 
> > > equation.
> > > What am I doing wrong here? Is it possible to model the grain impingement 
> > > problem in a user defined geometry and mesh created using gmsh? Or is 
> > > there any other approach in FiPy to achieve the same goal?
> > > I use windows platform,
> > > Python 2.7
> > > FiPy 3.1.3.
> > >
> > > Thanks,
> > >
> > > --
> > > Sachin Kurian
> > >
> > > ___
> > > 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 ]
> >
> >
> >
> > --
> > Sachin Kurian
> > Graduate Student
> > Department of Mechanical Engineering
> > Virginia Tech
> > ___
> > 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 ]
> 
> 
> 
> -- 
> Sachin Kurian
> Graduate Student
> Department of Mechanical Engineering
> Virginia Tech
> ___
> 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: Using ModularVariable in a mesh generated by gmsh

[Guyer, Jonathan E. Dr. (Fed)]

SkewedGrid2D is a defined thing in FiPy.

GmshGrid2D and GmshGrid3D have a _meshSpacing property defined, but making a 
generic periodic mesh with Gmsh will not induce this.


> On Feb 7, 2018, at 12:07 PM, Sachin Kurian <sach...@vt.edu> wrote:
> 
> Thank you.
> I've tried using quad meshes from gmsh (I suppose this is what you meant by 
> skew grids), but the same error shows up. So, the problem is that 
> '_meshSpacing' is not an attribute for 'Gmsh2D' mesh if I define a 
> ModularVariable on that mesh.
> 
> On Wed, Feb 7, 2018 at 11:49 AM, Guyer, Jonathan E. Dr. (Fed) 
> <jonathan.gu...@nist.gov> wrote:
> _meshSpacing is only implemented for (square (including skew)) grids and only 
> used by the _ModCellGradVariable. It's apparently been like that since before 
> FiPy was FiPy, 14 years ago.
> 
> I'll need to think about this more deeply to understand why normalizing by 
> grid spacing even makes sense, much less what the answer should be for a 
> general mesh.
> 
> 
> > On Feb 6, 2018, at 7:17 PM, Sachin Kurian <sach...@vt.edu> wrote:
> >
> > Hi everyone,
> >
> > I've just started using FiPy. I'm particularely interested in the phase 
> > field problems. I tried the examples of solidification and grain 
> > impingement given in the documentation. What I intend to do is to use a 
> > non-rectangular domain with triangular mesh for the problem. After 
> > importing the unstructured mesh generated by gmsh, I assigned a 
> > ModularVariable (theta) to the cells (Similar to the grain impingement 
> > examples). Unfortunately, assigning a ModularVariable to the Gmsh2D() mesh 
> > throws an attribute error:'Gmsh2D' object has no attribute '_meshSpacing'  
> > when I use theta.grad.mag command or try solving the equation.
> > What am I doing wrong here? Is it possible to model the grain impingement 
> > problem in a user defined geometry and mesh created using gmsh? Or is there 
> > any other approach in FiPy to achieve the same goal?
> > I use windows platform,
> > Python 2.7
> > FiPy 3.1.3.
> >
> > Thanks,
> >
> > --
> > Sachin Kurian
> >
> > ___
> > 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 ]
> 
> 
> 
> -- 
> Sachin Kurian
> Graduate Student
> Department of Mechanical Engineering
> Virginia Tech
> ___
> 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: Using ModularVariable in a mesh generated by gmsh

[Guyer, Jonathan E. Dr. (Fed)]

_meshSpacing is only implemented for (square (including skew)) grids and only 
used by the _ModCellGradVariable. It's apparently been like that since before 
FiPy was FiPy, 14 years ago.

I'll need to think about this more deeply to understand why normalizing by grid 
spacing even makes sense, much less what the answer should be for a general 
mesh.


> On Feb 6, 2018, at 7:17 PM, Sachin Kurian  wrote:
> 
> Hi everyone,
> 
> I've just started using FiPy. I'm particularely interested in the phase field 
> problems. I tried the examples of solidification and grain impingement given 
> in the documentation. What I intend to do is to use a non-rectangular domain 
> with triangular mesh for the problem. After importing the unstructured mesh 
> generated by gmsh, I assigned a ModularVariable (theta) to the cells (Similar 
> to the grain impingement examples). Unfortunately, assigning a 
> ModularVariable to the Gmsh2D() mesh throws an attribute error:'Gmsh2D' 
> object has no attribute '_meshSpacing'  when I use theta.grad.mag command or 
> try solving the equation.
> What am I doing wrong here? Is it possible to model the grain impingement 
> problem in a user defined geometry and mesh created using gmsh? Or is there 
> any other approach in FiPy to achieve the same goal?
> I use windows platform,
> Python 2.7
> FiPy 3.1.3.
> 
> Thanks,
> 
> -- 
> Sachin Kurian
> 
> ___
> 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: How to declare diffusion function

[Guyer, Jonathan E. Dr. (Fed)]

Kevin -

You are correct that there's no way to project a FaceVariable back to a 
CellVariable. Since this is only for the initial condition, I would just 
explicitly set it, e.g.,

  phi.value = (1 + x) / (gamma * psi.grad[0])


As for the boundary condition, I think FiPy's default no-flux boundary 
condition will give you this naturally. Constraining the divergence of the 
gradient will not ever be seen by the solver.

- Jon

> On Feb 5, 2018, at 4:13 PM, Kevin Blondino  wrote:
> 
> Hi,
> 
> I have two questions.
> 
> I have a complicated set of 1D equations. The diffusion coefficient of the 
> 1st is dependent on the derivative of the 2nd's variable, and the 2nd has a 
> source term of the first. In addition, the initial condition of one of the 
> variables is dependent on this diffusion coefficient. This is what I mean, in 
> TeX:
> 
>   \alpha \frac{\partial \phi}{\partial t} = \frac{\partial}{\partial x} 
> \left(D \frac{\partial \phi}{\partial x}\right) \\
>   \beta \frac{\partial \psi}{\partial t} = m \frac{\partial^2 
> \psi}{\partial x^2} + \delta\phi \\
>   D = \gamma \left(\frac{\partial \psi}{\partial x}\right)^{-1} \\
>   \phi_0 = \frac{1 + x}{D}
> 
> alpha, beta, gamma, delta, and m are constants, and phi and psi are the Cell 
> Variables. How can properly write and implement the diffusion coefficient D?
> 
> So far, I've been trying to implement it by declaring D as a CellVariable, 
> but as it's a diffusion function, it would seem natural to have it as a 
> FaceVariable. The problem arises when I try to use it for the initial 
> condition, as I cannot make phi_0 a function of D as a face variable.
> 
> 
> In addition, one of the boundary conditions is this (at x=0):
> 
>   \frac{\partial \psi^2}{\partial x^2} = 0
> 
> I've been implementing it as the following, but I am not sure if it works 
> properly:
> 
>   psi.faceGrad.divergence.constrain(0.0, mesh.facesLeft)
> 
> Thank you
> 
> ___
> 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: Gradient in cylindrical coordinates

[Guyer, Jonathan E. Dr. (Fed)]

Leyton -

A compressible flow example contribution would be most welcome! Please submit a 
[pull request](https://github.com/usnistgov/fipy/pulls) and we'll work with you 
to get it integrated and released. 
[don't hesitate to ask if you need help making the pull request]

- Jon

> On Jan 5, 2018, at 7:23 PM, Munoz Leyton  
> wrote:
> 
> I would like also to contribute to the community with an example of  
> compressible flow with euler equations in 2D Cartesian coordinates. I 
> validated the results with SOD shock tube and I was quite happy with it. With 
> whom should I talk to review it and possibly upload it?
> 


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

Re: Compute total free energy of a system

[Guyer, Jonathan E. Dr. (Fed)]

I believe (...).cellVolumeAverage * mesh.cellVolumes.sum() is what you want.


> On Jan 4, 2018, at 10:49 AM, Daniel Wheeler  wrote:
> 
> You might want to multiply by the cell volumes, "mesh.cellVolumes".
> 
> On Thu, Jan 4, 2018 at 10:22 AM, Anders Ericsson
>  wrote:
>> Hi,
>> 
>> 
>> I wonder if there is a simple way to compute the total free energy of a
>> system (Phase-field modeling) in FiPy?
>> 
>> 
>> That is e.g.:
>> 
>> 
>> \begin{equation}
>> F = \int_V f(\phi, c, T) + \frac{\epsilon_{\phi}^2}{2}\nabla \phi^2 dV
>> \end{equation}
>> 
>> I figured that it would be something in accordance with:
>> 
>> def freeEnergyVolume(phi_, c_, T, epsSq):
>>return (0.5 * epsSq * (phi_.grad.mag)**2 +
>> f(phi_,c_,T)).cellVolumeAverage
>> 
>> But cellVolumeAverage wouldn't give me the full energy of the domain if I'm
>> not mistaken?
> 
> 
> -- 
> 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: How to represent strange terms in FiPy

[Guyer, Jonathan E. Dr. (Fed)]

Sorry for the slow reply.

Expressions like [(1.0/density),] and [(temperature / density**2),] 
unfortunately don't work reliably in FiPy. They might work, but I wouldn't 
count on it.

The issue is that FiPy sees a Python list that holds the instantaneous value of 
a rank-0 CelVariable, rather than seeing a rank-1 CellVariable that can change. 
This is down to Python syntax that FiPy doesn't get a chance reinterpret.

I believe you'll have better luck with numerix.dot((1.0/density) * [[1.]], 
temperature.grad) and numerix.dot((temperature / density**2) * [[1]], 
density.grad).

You could as readily write (1.0/density) * temperature.grad[0] and (temperature 
/ density**2) * density.grad[0]. It depends on what you really mean, which 
usually is clearer in higher dimensions.

> On Dec 14, 2017, at 12:26 PM, Kevin Blondino <kablond...@gmail.com> wrote:
> 
> Hi,
> 
> I've adjusted the system a little bit, and I wanted some verification and 
> more criticism.
> 
> I took your suggestions about (Z.grad)**2 and changed it to 
> numerix.dot(Z.grad, Z.grad) to give me a scalar.
> 
> In addition, the terms that could not be easily written as convection terms:
> \begin{align}
> \frac{1}{n} \frac{\partial T}{\partial x} + \frac{T}{n^2} 
> \frac{\partial n}{\partial x}
> \end{align}
> 
> I wrote them by making the coefficients a vector and then dotting with the 
> gradient:
> numerix.dot([(1.0/density),], temperature.grad) + 
> numerix.dot([(temperature / density**2), ], density.grad)
> 
> Are these things a fair / reasonable thing to do? I have looked over my 
> system in the most original form and it seems there is no way to show them in 
> a ConvectionTerm or ImplicitSourceTerm.
> 
> I apologize if the code is a little difficult to read.
> 
> Thanks,
> Kevin
> 
> On 12 December 2017 at 16:37, Guyer, Jonathan E. Dr. (Fed) 
> <jonathan.gu...@nist.gov> wrote:
> Kevin -
> 
> - Should I model the last term in the temperature (T) equations as a 
> convection term or explicit source term?
> 
> The best coupling would be obtained by treating this term as a convection 
> term on n with a velocity proportional to \partial T/\partial x. 
> Unfortunately, (D/n) sits outside the derivatives and so FiPy has no implicit 
> way to represent it. I think you're stuck with the source.
> 
> - What about the "S_Z" term in the Z equation?
> 
> Again, as written, these are just sources.
> 
> - Is it required that I declare diffusivity (D) as a cell variable, as it is 
> now?
> 
> In order to write an equation to solve for D, it must be a CellVariable, 
> however, there's no advantage in adding this as  a solution equation. I would 
> just define D as a function of Z. As such, it's better to define it as a 
> FaceVariable for use in the DiffusionTerms.
> 
> Note:
> 
> The expressions Z*(Z.grad) and (Z.grad)**2 amount to multiplying a scalar by 
> a vector and a vector by a vector, but D needs to be scalar. I recommend 
> working out what your equations would be using either divergence and gradient 
> operators or Einstein notation, as premature introduction of d/dx in 1D 
> equations leads to equations that are difficult to debug and render properly.
> 
> You may find that when you go back to the source equations in general 
> vectorial form that the sources in the T and Z equations are amenable to 
> being written as convection terms or implicit sources, which would be good.
> 
> - Jon
> 
> 
> > On Dec 11, 2017, at 2:42 PM, Kevin Blondino <kablond...@gmail.com> wrote:
> >
> > Hello,
> >
> > I have a somewhat complicated system of highly nonlinear, 1D PDE's which I 
> > am having trouble modeling. The issue is that I am not sure how to 
> > represent certain terms.
> >
> > Here is a the following LaTeX code for the system, as to make sure there is 
> > no ambiguity:
> > \begin{align}
> >   \frac{\partial n}{\partial t} \,&=\, \frac{\partial}{\partial 
> > x}\left(D \frac{\partial n}{\partial x}\right) \\
> >   \frac{\partial T}{\partial t} \,&=\, \frac{\partial}{\partial 
> > x}\left(D \frac{\partial T}{\partial x}\right) + 
> > \frac{D}{n}\,\frac{\partial n}{\partial x}\,\frac{\partial T}{\partial x} \\
> >   \frac{\partial Z}{\partial t} \,&=\, \frac{\partial}{\partial 
> > x}\left(D \frac{\partial Z}{\partial x}\right) + 
> > \frac{T}{n^2}\frac{\partial n}{\partial x} + \frac{1}{n}\frac{\partial 
> > T}{\partial x} + G(Z) \\
> >   G(Z) \,&=\, a + b(Z - Z_S) + c(Z - Z_S)^3 \\
> >   D \,&=\, 1 + \frac{1}{1 + Z^2 + Z\cdot\frac{\partial Z}{\partial x} + 
> > \left(\frac{\partial Z}{\partial x}\right)

Re: How to represent strange terms in FiPy

[Guyer, Jonathan E. Dr. (Fed)]

Kevin -

- Should I model the last term in the temperature (T) equations as a convection 
term or explicit source term?

The best coupling would be obtained by treating this term as a convection term 
on n with a velocity proportional to \partial T/\partial x. Unfortunately, 
(D/n) sits outside the derivatives and so FiPy has no implicit way to represent 
it. I think you're stuck with the source.

- What about the "S_Z" term in the Z equation?

Again, as written, these are just sources.

- Is it required that I declare diffusivity (D) as a cell variable, as it is 
now?

In order to write an equation to solve for D, it must be a CellVariable, 
however, there's no advantage in adding this as  a solution equation. I would 
just define D as a function of Z. As such, it's better to define it as a 
FaceVariable for use in the DiffusionTerms.

Note: 

The expressions Z*(Z.grad) and (Z.grad)**2 amount to multiplying a scalar by a 
vector and a vector by a vector, but D needs to be scalar. I recommend working 
out what your equations would be using either divergence and gradient operators 
or Einstein notation, as premature introduction of d/dx in 1D equations leads 
to equations that are difficult to debug and render properly.

You may find that when you go back to the source equations in general vectorial 
form that the sources in the T and Z equations are amenable to being written as 
convection terms or implicit sources, which would be good.

- Jon


> On Dec 11, 2017, at 2:42 PM, Kevin Blondino  wrote:
> 
> Hello,
> 
> I have a somewhat complicated system of highly nonlinear, 1D PDE's which I am 
> having trouble modeling. The issue is that I am not sure how to represent 
> certain terms.
> 
> Here is a the following LaTeX code for the system, as to make sure there is 
> no ambiguity:
> \begin{align}
>   \frac{\partial n}{\partial t} \,&=\, \frac{\partial}{\partial x}\left(D 
> \frac{\partial n}{\partial x}\right) \\
>   \frac{\partial T}{\partial t} \,&=\, \frac{\partial}{\partial x}\left(D 
> \frac{\partial T}{\partial x}\right) + \frac{D}{n}\,\frac{\partial 
> n}{\partial x}\,\frac{\partial T}{\partial x} \\
>   \frac{\partial Z}{\partial t} \,&=\, \frac{\partial}{\partial x}\left(D 
> \frac{\partial Z}{\partial x}\right) + \frac{T}{n^2}\frac{\partial 
> n}{\partial x} + \frac{1}{n}\frac{\partial T}{\partial x} + G(Z) \\
>   G(Z) \,&=\, a + b(Z - Z_S) + c(Z - Z_S)^3 \\
>   D \,&=\, 1 + \frac{1}{1 + Z^2 + Z\cdot\frac{\partial Z}{\partial x} + 
> \left(\frac{\partial Z}{\partial x}\right)^2}
> \end{align}
> 
> I have purposefully squelched many coefficients as possible to make simple.
> 
> The main code I have been using to model them is as follows:
> 
>   # - Variable Declarations -
>   density = CellVariable(name=r"$n$", mesh=mesh, hasOld=True)
> 
>   temperature = CellVariable(name=r"$T$", mesh=mesh, hasOld=True)
> 
>   Z = CellVariable(name=r"$Z$", mesh=mesh, hasOld=True)
> 
>   ## Diffusivity
>   D = CellVariable(name=r"$D$", mesh=mesh, hasOld=True)
> 
>   ... (initial and boundary conditions are here) ...
> 
>   # - PDE Declarations --
>   # Diffusivity Equation (D)
>   diffusivity_equation = ImplicitSourceTerm(coeff=1.0, var=D) == 1.0 + 
> 1.0 / (1 + Z**2 + Z*(Z.grad) + (Z.grad)**2)
> 
> 
>   # Density Equation (n)
>   density_equation = TransientTerm(var=density) == DiffusionTerm(coeff=D, 
> var=density)
> 
> 
>   # Temperature Equation (T)
>   S_T = (D/density) * numerix.dot(density.grad,temperature.grad) # ???
>   S_T_conv = ConvectionTerm(coeff=(D/density)*density.grad, 
> var=temperature) # ??
> 
>   temp_equation = TransientTerm(var=temperature) == 
> DiffusionTerm(coeff=D, var=temperature) + S_T
> 
> 
>   # Z Equation
>   G = a + b*(Z - Z_S) + c*(Z - Z_S)**3
>   S_Z = G + (1 / density)*temperature.grad.mag + (temperature / 
> density**2)*density.grad.mag # ???
>   Z_equation = TransientTerm(coeff=1.0, var=Z) == DiffusionTerm(coeff=D, 
> var=Z) + S_Z
> 
>   # Fully-Coupled Equation
>   full_equation = density_equation & temp_equation & Z_equation & 
> diffusivity_equation
> 
> Should I model the last term in the temperature (T) equations as a convection 
> term or explicit source term?
> What about the "S_Z" term in the Z equation?
> Is it required that I declare diffusivity (D) as a cell variable, as it is 
> now?
> 
> I appreciate any help that can be given.
> 
> Thank you,
> Kevin
> ___
> 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

[Guyer, Jonathan E. Dr. (Fed)]

I've filled [an issue](https://github.com/usnistgov/fipy/issues/530)

> On Nov 13, 2017, at 10:04 AM, Guyer, Jonathan E. Dr. (Fed) 
> <jonathan.gu...@nist.gov> wrote:
> 
> Not noise. We'll amend the instructions to make this clear.
> 
>> On Nov 9, 2017, at 5:25 PM, James Pringle <jprin...@unh.edu> wrote:
>> 
>> Worked fine.
>> Thank you, and apologize for the noise
>> Jamie
>> 
>> On Thu, Nov 9, 2017 at 3:44 AM, Benny Malengier <benny.maleng...@gmail.com> 
>> wrote:
>> 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 <jprin...@unh.edu>:
>> 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 ]
> 
> 
> ___
> 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: 2D anisotropic unstructured mesh and non-classical FV schemes

[Guyer, Jonathan E. Dr. (Fed)]

Daniel is much better versed in the nuances of FV schemes than I am, but I did 
want to question one assertion you made: 

> On Oct 16, 2017, at 6:16 PM, F Hssn  wrote:
> 
> If you wish to use an unstructured Delaunay mesh, it has
> to be isotropic (equilateral triangles) or near-isotropic otherwise
> the control volume calculation will result in overlaps and the
> conservation property will be violated (the solution would more likely
> be incorrect).

CC-FVM is a direct discretization of the divergence theorem. As such, I'm 
pretty sure it is guaranteed to be conservative.

Non-orthogonality will lead to fluxes being wrong, but they will still be 
conservative (whatever they flux out of one cell, they deposit in the neighbor).


> On Oct 17, 2017, at 4:07 PM, F Hssn  wrote:
> 
>> What is an anisotropic mesh?
> 
> By anisotropic, I mean the mesh having low-quality triangles (skinny
> triangles, as opposed to equilateral triangles), strategically
> oriented so they reduce the number of vertices required but do not
> negatively affect the resolution of the functions or solutions
> involved (e.g., the interpolation error does not increase compared to
> an isotropic mesh where all triangles are equilateral or
> near-equilateral).
> 
> bamg is a good anisotropic mesh generator and its user manual [1]
> contains examples of anisotropic meshes (e.g., Fig 12 on page 14).
> 
> I should point out that when I say anisotropic quad-tree based
> axis-aligned mesh, I really mean quasi-ansiotropy, since an
> axis-aligned mesh can only orient skinny triangles along x or y axis.
> If your solution has an interface layer that is oriented in neither,
> e.g., if it's at a 45 degree angle, an axis-aligned mesh would not be
> able to make use of anisotropy and would end up using way more
> vertices instead (for constructing small rectangles along the layer).
> (An illustration of an axis-aligned mesh: 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fimgur.com%2F15pyjHG=02%7C01%7Cjonathan.guyer%40nist.gov%7C0cd9082479634078c46808d5159ac7e0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636438676887192908=SdR7MZg8rnTndTHH5p%2Fqxxni8s4KPo1KQLubiNVAMQg%3D=0)
> 
> [1] 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ljll.math.upmc.fr%2Fhecht%2Fftp%2Fbamg%2Fbamg.pdf=02%7C01%7Cjonathan.guyer%40nist.gov%7C0cd9082479634078c46808d5159ac7e0%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636438676887192908=ATMC%2FZGC9k5g%2FIs%2BqED%2F1sFbMIp90LK84urX3Py6RS4%3D=0
> ___
> 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: 2D Periodic Grid in Parallel

[Guyer, Jonathan E. Dr. (Fed)]

Jonathan -

I see what you're talking about. Fixing (or even working around) has proven 
elusive so far, but I'm working on it.

- Jon

> On Sep 20, 2017, at 10:02 AM, Jonathan Smyth  wrote:
> 
> Hello,
> 
> I am working on a 2D simulation of the drift-diffusion model for 
> semiconductors, and I'm having some difficulty with 2D periodic boundary 
> conditions when running in parallel. It seems that when using PeriodicGrid2D 
> in parallel each "chunk" of the mesh becomes periodic rather than the whole 
> mesh being periodic, which causes some strange results.  Since the mesh is 
> broken up into horizontal slices when in parallel, only the top-bottom 
> boundaries are affected by this. Is there any sort of work around for this 
> problem?
> 
> Many thanks,
> Jonathan
> ---
> 
> Jonathan Smyth
> Atomistic Simulation Centre
> School of Maths and Physics
> Queen's University Belfast
> ___
> 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 Interest: Question about Diffusion and Convection Terms

[Guyer, Jonathan E. Dr. (Fed)]

Nicholas -

Please see the end of 
https://www.ctcms.nist.gov/fipy/examples/diffusion/generated/examples.diffusion.mesh1D.html

Search for the text "Often, the diffusivity is not only non-uniform, but also 
depends on the value of the variable" (the Search function built into the web 
page isn't working for some reason).

- Jon


> On Sep 6, 2017, at 1:36 PM, Nicholas Danes  wrote:
> 
> To whom it may concern,
> 
> I was looking into using the FiPy package for my research and I was wondering 
> if it's possible to modify the diffusion and convection terms  at each cell 
> as a function of space of another solution variable? This is assuming a 
> CC-FVM approach. 
> 
> If so, can someone point either to a minimal example or a link in the 
> developers library on how one would do this?
> 
> 
> 
> Best,
> 
> Nicholas A. Danes
> PhD Candidate  | Computational & Applied Math | Colorado School of Mines
> 
> 
> ___
> 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: PyTrilinos import error Mac OS

[Guyer, Jonathan E. Dr. (Fed)]

I'm glad I could help. Hopefully the conda devs will show me how to get a 
complete solution to what's still pretty broken.


> On Aug 25, 2017, at 1:12 PM, Seufzer, William J. (LARC-D307) 
> <bill.seuf...@nasa.gov> wrote:
> 
> Success!
> 
> Here are the results from running parallel.py in the FiPy examples folder.
> 
> (pytril) examples: mpirun -np 4 python parallel.py 
> mpi4py: processor 0 of 4 :: PyTrilinos: processor 0 of 4 :: FiPy: 4 cells on 
> processor 0 of 4
> mpi4py: processor 1 of 4 :: PyTrilinos: processor 1 of 4 :: FiPy: 6 cells on 
> processor 1 of 4
> mpi4py: processor 3 of 4 :: PyTrilinos: processor 3 of 4 :: FiPy: 6 cells on 
> processor 3 of 4
> mpi4py: processor 2 of 4 :: PyTrilinos: processor 2 of 4 :: FiPy: 6 cells on 
> processor 2 of 4
> 
> Thanks!
> 
> Bill Seufzer, PhD
> NASA Langley Research Center
> 
>> On Aug 25, 2017, at 12:54 PM, Guyer, Jonathan E. Dr. (Fed) 
>> <jonathan.gu...@nist.gov> wrote:
>> 
>> OK, multiple things are messed up here and I'm not sure any of them are 
>> related to Apple possibly moving things. 
>> 
>> Things should work on Mac OS X and Linux with:
>> 
>> conda create --name  --channel guyer --channel conda-forge fipy 
>> nomkl
>> 
>> 
>> 
>> Note, this does not work on Windows. On that platform, you should be able to 
>> do:
>> 
>> conda create --name  --channel guyer --channel conda-forge python 
>> numpy scipy matplotlib mayavi
>> source activate 
>> pip install fipy
>> 
>> There are presently no conda packages of any solver suite but scipy 
>> available for Windows.
>> 
>> 
>>> On Aug 22, 2017, at 12:03 PM, Guyer, Jonathan E. Dr. (Fed) 
>>> <jonathan.gu...@nist.gov> wrote:
>>> 
>>> Apple moved something between 10.11 and 10.12. It looks like my rebuild for 
>>> 10.12 from a few weeks ago broke 10.11. I'll have to figure out how to post 
>>> both versions (and rebuild the 10.11 version at all).
>>> 
>>> 
>>>> On Aug 22, 2017, at 9:58 AM, Seufzer, William J. (LARC-D307) 
>>>> <bill.seuf...@nasa.gov> wrote:
>>>> 
>>>> I get the following error on Mac OS 10.11.6 (Xcode 8.2.1 w/ command line 
>>>> tools installed). I used:
>>>> 
>>>> conda create --name pytril --channel guyer --channel condo-forge fipy
>>>> 
>>>> to create the environment (BTW, thanks for setting that up!!)
>>>> 
>>>> Father Google doesn’t seem to be of any help on this one.
>>>> 
>>>> The error:
>>>> 
>>>> (pytril) ~: python
>>>> Python 2.7.13 | packaged by conda-forge | (default, May  2 2017, 13:29:36) 
>>>> [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>>> from mpi4py import MPI
>>>>>>> from PyTrilinos import Epetra
>>>> Traceback (most recent call last):
>>>> File "", line 1, in 
>>>> File 
>>>> "/Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/Epetra.py",
>>>>  line 78, in 
>>>> _Epetra = swig_import_helper()
>>>> File 
>>>> "/Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/Epetra.py",
>>>>  line 74, in swig_import_helper
>>>> _mod = imp.load_module('_Epetra', fp, pathname, description)
>>>> ImportError: 
>>>> dlopen(/Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/_Epetra.so,
>>>>  258): Symbol not found: _cgesv_
>>>> Referenced from: 
>>>> /Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/../../..//libteuchosnumerics.11.dylib
>>>> Expected in: 
>>>> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
>>>> in 
>>>> /Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/../../..//libteuchosnumerics.11.dylib
>>>>>>> 
>>>> 
>>>> I’m on a centrally managed Mac, so OS update is not an option. Xcode, gcc, 
>>>> and Conda install are under my control.
>>>> 
>>>> Thanks,
>>>> 
>>>> Bill
>>>> 
>>>> ___
>>>> 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 ]
>> 
>> 
>> ___
>> 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 ]


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

Re: PyTrilinos import error Mac OS

[Guyer, Jonathan E. Dr. (Fed)]

Make that `activate ` on Windows

> On Aug 25, 2017, at 12:54 PM, Guyer, Jonathan E. Dr. (Fed) 
> <jonathan.gu...@nist.gov> wrote:
> 
> OK, multiple things are messed up here and I'm not sure any of them are 
> related to Apple possibly moving things. 
> 
> Things should work on Mac OS X and Linux with:
> 
>  conda create --name  --channel guyer --channel conda-forge fipy 
> nomkl
> 
> 
> 
> Note, this does not work on Windows. On that platform, you should be able to 
> do:
> 
>  conda create --name  --channel guyer --channel conda-forge python 
> numpy scipy matplotlib mayavi
>  source activate 
>  pip install fipy
> 
> There are presently no conda packages of any solver suite but scipy available 
> for Windows.
> 
> 
>> On Aug 22, 2017, at 12:03 PM, Guyer, Jonathan E. Dr. (Fed) 
>> <jonathan.gu...@nist.gov> wrote:
>> 
>> Apple moved something between 10.11 and 10.12. It looks like my rebuild for 
>> 10.12 from a few weeks ago broke 10.11. I'll have to figure out how to post 
>> both versions (and rebuild the 10.11 version at all).
>> 
>> 
>>> On Aug 22, 2017, at 9:58 AM, Seufzer, William J. (LARC-D307) 
>>> <bill.seuf...@nasa.gov> wrote:
>>> 
>>> I get the following error on Mac OS 10.11.6 (Xcode 8.2.1 w/ command line 
>>> tools installed). I used:
>>> 
>>> conda create --name pytril --channel guyer --channel condo-forge fipy
>>> 
>>> to create the environment (BTW, thanks for setting that up!!)
>>> 
>>> Father Google doesn’t seem to be of any help on this one.
>>> 
>>> The error:
>>> 
>>> (pytril) ~: python
>>> Python 2.7.13 | packaged by conda-forge | (default, May  2 2017, 13:29:36) 
>>> [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>> from mpi4py import MPI
>>>>>> from PyTrilinos import Epetra
>>> Traceback (most recent call last):
>>> File "", line 1, in 
>>> File 
>>> "/Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/Epetra.py",
>>>  line 78, in 
>>>  _Epetra = swig_import_helper()
>>> File 
>>> "/Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/Epetra.py",
>>>  line 74, in swig_import_helper
>>>  _mod = imp.load_module('_Epetra', fp, pathname, description)
>>> ImportError: 
>>> dlopen(/Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/_Epetra.so,
>>>  258): Symbol not found: _cgesv_
>>> Referenced from: 
>>> /Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/../../..//libteuchosnumerics.11.dylib
>>> Expected in: 
>>> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
>>> in 
>>> /Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/../../..//libteuchosnumerics.11.dylib
>>>>>> 
>>> 
>>> I’m on a centrally managed Mac, so OS update is not an option. Xcode, gcc, 
>>> and Conda install are under my control.
>>> 
>>> Thanks,
>>> 
>>> Bill
>>> 
>>> ___
>>> 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 ]
> 


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

Re: PyTrilinos import error Mac OS

[Guyer, Jonathan E. Dr. (Fed)]

OK, multiple things are messed up here and I'm not sure any of them are related 
to Apple possibly moving things. 

Things should work on Mac OS X and Linux with:

  conda create --name  --channel guyer --channel conda-forge fipy 
nomkl



Note, this does not work on Windows. On that platform, you should be able to do:

  conda create --name  --channel guyer --channel conda-forge python 
numpy scipy matplotlib mayavi
  source activate 
  pip install fipy

There are presently no conda packages of any solver suite but scipy available 
for Windows.


> On Aug 22, 2017, at 12:03 PM, Guyer, Jonathan E. Dr. (Fed) 
> <jonathan.gu...@nist.gov> wrote:
> 
> Apple moved something between 10.11 and 10.12. It looks like my rebuild for 
> 10.12 from a few weeks ago broke 10.11. I'll have to figure out how to post 
> both versions (and rebuild the 10.11 version at all).
> 
> 
>> On Aug 22, 2017, at 9:58 AM, Seufzer, William J. (LARC-D307) 
>> <bill.seuf...@nasa.gov> wrote:
>> 
>> I get the following error on Mac OS 10.11.6 (Xcode 8.2.1 w/ command line 
>> tools installed). I used:
>> 
>> conda create --name pytril --channel guyer --channel condo-forge fipy
>> 
>> to create the environment (BTW, thanks for setting that up!!)
>> 
>> Father Google doesn’t seem to be of any help on this one.
>> 
>> The error:
>> 
>> (pytril) ~: python
>> Python 2.7.13 | packaged by conda-forge | (default, May  2 2017, 13:29:36) 
>> [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> from mpi4py import MPI
>>>>> from PyTrilinos import Epetra
>> Traceback (most recent call last):
>> File "", line 1, in 
>> File 
>> "/Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/Epetra.py",
>>  line 78, in 
>>   _Epetra = swig_import_helper()
>> File 
>> "/Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/Epetra.py",
>>  line 74, in swig_import_helper
>>   _mod = imp.load_module('_Epetra', fp, pathname, description)
>> ImportError: 
>> dlopen(/Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/_Epetra.so,
>>  258): Symbol not found: _cgesv_
>> Referenced from: 
>> /Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/../../..//libteuchosnumerics.11.dylib
>> Expected in: 
>> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
>> in 
>> /Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/../../..//libteuchosnumerics.11.dylib
>>>>> 
>> 
>> I’m on a centrally managed Mac, so OS update is not an option. Xcode, gcc, 
>> and Conda install are under my control.
>> 
>> Thanks,
>> 
>> Bill
>> 
>> ___
>> 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 ]


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

Re: PyTrilinos import error Mac OS

[Guyer, Jonathan E. Dr. (Fed)]

Apple moved something between 10.11 and 10.12. It looks like my rebuild for 
10.12 from a few weeks ago broke 10.11. I'll have to figure out how to post 
both versions (and rebuild the 10.11 version at all).


> On Aug 22, 2017, at 9:58 AM, Seufzer, William J. (LARC-D307) 
>  wrote:
> 
> I get the following error on Mac OS 10.11.6 (Xcode 8.2.1 w/ command line 
> tools installed). I used:
> 
> conda create --name pytril --channel guyer --channel condo-forge fipy
> 
> to create the environment (BTW, thanks for setting that up!!)
> 
> Father Google doesn’t seem to be of any help on this one.
> 
> The error:
> 
> (pytril) ~: python
> Python 2.7.13 | packaged by conda-forge | (default, May  2 2017, 13:29:36) 
> [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
 from mpi4py import MPI
 from PyTrilinos import Epetra
> Traceback (most recent call last):
>  File "", line 1, in 
>  File 
> "/Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/Epetra.py",
>  line 78, in 
>_Epetra = swig_import_helper()
>  File 
> "/Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/Epetra.py",
>  line 74, in swig_import_helper
>_mod = imp.load_module('_Epetra', fp, pathname, description)
> ImportError: 
> dlopen(/Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/_Epetra.so,
>  258): Symbol not found: _cgesv_
>  Referenced from: 
> /Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/../../..//libteuchosnumerics.11.dylib
>  Expected in: 
> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
> in 
> /Users/wseufzer/anaconda3/envs/pytril/lib/python2.7/site-packages/PyTrilinos/../../..//libteuchosnumerics.11.dylib
 
> 
> I’m on a centrally managed Mac, so OS update is not an option. Xcode, gcc, 
> and Conda install are under my control.
> 
> Thanks,
> 
> Bill
> 
> ___
> 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: Convergence problem while increasing domain size

[Guyer, Jonathan E. Dr. (Fed)]

Clara -

The mesh needs to be fine enough to resolve the interfaces. How thick is the 
phase interface for your parameters? Generally, you need O(10) grid points 
across the interface.

- Jon


> On Jul 25, 2017, at 1:50 PM, Clara Maurel  wrote:
> 
> Hello,
> 
> Sorry in advance if my question is very basic. I am using fipy to solve a 
> Cahn-Hilliard equation problem, and it worked perfectly fine on a 1D domain 
> of size nx*dx where nx=500 and dx=0.5.
> I wanted to run on a larger domain, but in order to reduce the computation 
> time, I increase the spatial resolution; now the size of my domain is  nx*dx 
> where nx=2500 and dx=2. This lead to a diverging solution for all my runs.
> 
> I was wondering whether there was optimal ratios of nx and dx, or length and 
> dx, which had to be implemented so that the code does not diverge even on a 
> greater scale? Or if not, if anyone had an idea of what could be going on, 
> given that I only did this change between the two versions of the code.
> 
> Thank you in advance for you help!
> 
> Clara___
> 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: Using FiPy to solve a 1D diffusion problem under a potential profile

[Guyer, Jonathan E. Dr. (Fed)]

Other than a change of sign on the ConvectionTerm, I don't see any problem with 
how you wrote your equation.

There's not much to do to debug a seg fault, other than isolate what line of 
code is causing it. Comment out all the lines in your code and successively add 
them until the seg fault occurs.

How big is your mesh? 

If you create a Viewer with U_z, does it look like you think it should from 
your experimental data?

What are the four failures when you run `python setup.py test`? If something 
deeply was wrong, I'd expect many more than 4 failures, but it still might be 
helpful to know.

- Jon

> On Jul 18, 2017, at 4:42 AM, WANG Lingjian  wrote:
> 
> Hello everyone, I am trying to solve a 1D diffusion problem in a shape like 
> the following equation using FiPy.  Where U(z) is a 1D potential fitted from 
> experiment data. I created this U_z as a CellVariable like the following: ``` 
> U_z = CellVariable(name="potential", mesh=mesh) 
> U_z.setValue(fitted_function(x) * D * beta) ``` >From my understanding, this 
> equation can be interpreted using FiPy syntax as ``` F_z = U_z.faceGrad eqX = 
> TransientTerm() == (DiffusionTerm(coeff=D) + ConvectionTerm(coeff=F_z)) ``` 
> But when I try to solve it using commands that look like this, ``` for step 
> in range(steps): eqX.solve(var=phi, dt=timeStepDuration) print "time step at 
> {}".format(step) viewer.plot() ``` I encounter a Segmentation fault error 
> with no further information indicating any possible error. Could anyone tell 
> me: #1 Is there any misunderstanding in the above processes(i.e. treating the 
> dU/dz term as a ConvectionTerm, using .faceGrad ...)? #2 Is there any option 
> for debugging the !
 Segmentation fault error? Thanks in advance. In case that software environment 
issue, I provide some system information and FiPy test information below. 
[SYSTEM INFO] System: fedora17(Beefy Miracle) Python version: anaconda2 4.4.0 
FiPy installation method: "conda create --name MYFIPYENV --channel guyer 
--channel conda-forge fipy" . [FiPy test status] Testing of FiPy using ``` 
python -c "import fipy; fipy.test()" ``` Fails with AttributeError: 'module' 
object has no attribute 'testFiPy'. But test using ``` python setup.py test ``` 
under the FiPy source folder gives ### FAILED (failures=4) 
!!! 
Skipped 45 doctest examples because neither `lsmlib` nor `skfmm` can be found 
on the $PATH Skipped 2 doctest examples because `lsmlib` must be used to run 
some tests Skipped 1 doctest examples because `skfmm` must be used to run some 
tests ### _!
 __
> 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 ]