Re: nonlinear transient coefficient

ilto: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

RE: nonlinear transient coefficient

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 On Behalf Of Guyer, Jonathan E. Dr. (Fed) via fipy Sent: lauantai 23. toukokuuta 2020 19.08 To: FIPY Subject: Re: nonlinear transient

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

Re: Setting up boundary conditions

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

Re: Axes scales for 2D mesh

Hi Jonathan, Thanks for the quick response. I tried your suggestion but it appears that the only thing that gets rescaled is the window of the graph and not the graph itself. I added the picture that I obtain. When I run the code I get the following warnings. Maybe this has something to do with it

Re: Axes scales for 2D mesh

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 an

Re: Help with 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

Re: Help with FiPy

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 langua

Re: Help with 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

Re: Implementation of Dirichlet Boundary Condition

I did a new commit where the checks run successfully. See on github. Hope this is will help you. I did my best. Warm regards, Alex Am 10.03.20 um 20:29 schrieb Guyer, Jonathan E. Dr. (Fed) via fipy: > The change you propose is inconsistent with the convection scheme, as > evidenced by the large

Re: Charge dynamics and Neumann boundary conditions

Hi Jon, I tried to fix the the value of +v and -v on the right and left by the following code (for the Robin boundary condition) (RobinCoeff * g*n).divergence - fp.ImplicitSourceTerm(coeff=(RobinCoeff).divergence, var=phi) and I also added -fp.ImplicitSourceTerm(coeff=(RobinCoeff).div

Re: Charge dynamics and Neumann boundary conditions

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 th

Re: Implementation of Dirichlet Boundary Condition

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

Re: Implementation of Dirichlet Boundary Condition

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

Re: Implementation of Dirichlet Boundary Condition

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

Re: Charge dynamics and Neumann boundary conditions

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 th

Re: Implementation of Dirichlet Boundary Condition

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 questio

Re: Charge dynamics and Neumann boundary conditions

Hi Jon, Since I am new to FiPy, it may take me awhile to follow through your solution. I am sure will have further questions. In the mean time, thank you so much for your prompt response. Best regard, Yuranan ___ fipy mailing list fipy@nist.gov ht

Re: Charge dynamics and Neumann boundary conditions

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/document

Re: Charge dynamics and Neumann boundary conditions

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

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

> 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

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

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

Re: ANN: FiPy 3.4

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 improv

Re: ANN: FiPy 3.4

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 consi

Re: ANN: FiPy 3.4

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

Re: Some questions on the viewer

On Thu, Jan 23, 2020 at 11:37 AM Guyer, Jonathan E. Dr. (Fed) via fipy wrote: > > 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 wou

Re: Some questions on the viewer

ectly. 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/py

Re: Some questions on the viewer

pe 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

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

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 po

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

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 th

Re: Some questions on the viewer

anging 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

Re: Some questions on the viewer

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: [image: Untitled.png] On another note, I've posted some stuff on github which may

Re: Some questions on the viewer

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/discr

Re: Some questions on the viewer

Dear Amine, In the end, my suggestion does not work... Instantiation of Viewer() in the Jupyter notebook always generates a spontaneous plot. We will have to live with it. (I do not know the equivalent of 'silent 1; pauseupdate" in Python Jupyter notebook). Also, on first Viewer() instantiation I

Re: Some questions on the viewer

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_analy

Re: Some questions on the viewer

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

Re: CylindricalGrid1D mesh volumes

On Fri, Jan 17, 2020 at 5:31 AM Pavel Aleynikov wrote: > > sort of ratio so the absolute value of the volume won't matter. > Unless you have a source with a defined integral absolute value. But I agree > that in general "theta = 1" is not a problem, as long as it's clear from the > documentation

Re: CylindricalGrid1D mesh volumes

Ok. I understand. I see the logic of saving on some operations. > Argulably, these quantities should be calculated in some > sort of ratio so the absolute value of the volume won't matter. Unless you have a source with a defined integral absolute value. But I agree that in general "theta = 1" is

Re: CylindricalGrid1D mesh volumes

On Wed, Jan 15, 2020 at 4:21 AM Pavel Aleynikov wrote: > > Hi, > > How are "mesh.cellVolumes" defined in fp.CylindricalGrid1D case? > The surface of a circle grid is not equal pi*r^2. > > import fipy as fp > L= 1.; nx = 1000 > mesh = fp.CylindricalGrid1D(dx=L/nx, nx=nx) > print(mesh.cellVolu

Re: Problem in dump.write for vector variables

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 >>

Re: Query on AdsorbingSurfactantEquation.py consumptionCoeff

Feel free to add any relevant comments to the issue, https://github.com/usnistgov/fipy/issues/690. On Mon, Jan 13, 2020 at 1:36 PM Daniel Wheeler wrote: > > Hi Chaitanya, > > I think you're correct. It seems that term should be multiplied by the > time step. The tests all pass with your change. W

Re: Query on AdsorbingSurfactantEquation.py consumptionCoeff

Hi Chaitanya, I think you're correct. It seems that term should be multiplied by the time step. The tests all pass with your change. Would you like to submit a pull-request for that change? The way time stepping works is a bit weird in that equation so it wasn't clear to me what my intention was

Re: Problem in dump.write for vector variables

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 muc

Re: Problem in dump.write for vector variables

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.

Re: Problem in dump.write for vector variables

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

Re: Problem in dump.write for vector variables

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/1

Re: Problem in dump.write for vector variables

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. -- Trevor Keller, Ph.D. Materials Science and Engineering Division National Institute of Standar

Re: Need help to set up the model

h.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

Re[5]: Need help to set up the model

2019-11-27 3:11:56 PM Subject: Re[4]: Need help to set up the model Hello Daniel, Thank you so much for your response. I pickled the necessary data required to run the model. please find attached file. Please let me know if you that works or if need anything else. Thanks Mohammad -

Re: Re[2]: Need help to set up the model

Hi Mohammad, I can't actually run the example because I don't have netCDF4 installed. Could you possible formulate a simpler example without that requirement? There are a number of things that I would change in the example, but I need to be able to run it to see if those are relevant to the issues

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 f

Re: Problems using Grid2D

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

Re: Problems using Grid2D

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

Re: Problems using Grid2D

> 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 Vari

Re: Problems using Grid2D

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

Re: Fluid Dynamic Basics

Thanks Daniel. I have to admit, I'm a bit surprised that these types of problems are a challenge in FiPy, but I appreciate the information. On Thu, Aug 29, 2019 at 3:06 PM Daniel Wheeler wrote: > Hi Daniel, > > Solving the flow equations isn't easy and we certainly don't provide > much guidance

Re: Fluid Dynamic Basics

Hi Daniel, Solving the flow equations isn't easy and we certainly don't provide much guidance on how to solve them with FiPy. We do have the Stokes cavity example [1] and reactive wetting example [2], which might be a good place for you to start. The Stokes cavity example demonstrates the simple a

Re: Boundary condition problem

x, 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 rang

Re: Boundary condition problem

=(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

Re: Boundary condition problem

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

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 Jian

Re: Boundary condition problem

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

Re: Drift Diffusion Equation Setup

d 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.potentia

Re: Drift Diffusion Equation Setup

rom: 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 mathem

Re: Drift Diffusion Equation Setup

y, 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 equ

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

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

ogdan 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. Bo

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 fa

Re: Drift Diffusion Equation Setup

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 fa

Re: Drift Diffusion Equation Setup

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

Re: Drift Diffusion Equation Setup

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 y

Re: Drift Diffusion Equation Setup

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 th

Re: Drift Diffusion Equation Setup

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 + Co

Re: ternary electrolyte

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, wh

Re: ternary electrolyte

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

Re: ternary electrolyte

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 ma

Re: ternary electrolyte

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

Re: ternary electrolyte

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, whic

Re: ternary electrolyte

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 wh

Re: ternary electrolyte

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

Re: ternary electrolyte

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(mes

Re: ternary electrolyte

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

Re: ternary electrolyte

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 species would need to also have zero gradient (like species 2 in the current solution). So

Re: ternary electrolyte

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.f

Re: Question regarding Boundary Condition Implementation

Jon, Thank you again for your advice. I'm guessing you discovered the mesh problem by visualizing the grid. I will have to remember that for future projects. I will also strongly consider a new boundary condition for the center line of the cylinder. Thank you, Dan On Mon, Apr 22, 2019 at 11:57

Re: 1D diffusion problem

Hi Jon, Thank you so much for taking the time to explain everything! Clara > On 22 Apr 2019, at 13:31, Guyer, Jonathan E. Dr. (Fed) via fipy > wrote: > > Also, the natural boundary condition for FiPy is no-flux, so there's no need > to do > > T_var.faceGrad.constrain(0, where=mesh.facesLef

Re: 1D diffusion problem

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

Re: 1D diffusion problem

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 o

Re: Question regarding Boundary Condition Implementation

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 thi

Re: A very basic question

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 ba

Re: Question regarding Boundary Condition Implementation

step for sweeps # Cylindrical coordinates time step #dt = 0.00005 #s,time step for sweeps steps = 150 #%% Universal Constants MW = 2.02#g H2 mol^-1 R = 8.314e-3# kj mol^-1 K^-1 #%% - air Properties T_in = 600. # K P_in = 1. # bar v = 0.5

Re: Question regarding Boundary Condition Implementation

> 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 som

Re: Question regarding Boundary Condition Implementation

Jonathan, Thank you very much for you help. It wouldn't be the first time I've over complicated a system. I understand how you set up the system a little bit better now. I had set things up the way I had before because I had expected to expand the system a bit. I was hoping to do the following: 1

Re: Setting CellVariable values

> 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/fi

Re: Setting CellVariable values

Thanks, makes sense. In my case, as I just have only one dimension, using sourceGrid.value[i] or sourceGrid[...,i] should be equivalent though? On Tue, Apr 9, 2019 at 3:32 PM Guyer, Jonathan E. Dr. (Fed) via fipy < fipy@nist.gov> wrote: > > On Apr 8, 2019, at 6:38 PM, Dario Panada wrote: > > >

Re: Setting CellVariable values

> 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 interna

Re: Setting CellVariable values

On Mon, Apr 8, 2019 at 11:22 PM Guyer, Jonathan E. Dr. (Fed) via fipy < fipy@nist.gov> wrote: > > > > 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 signi

Re: Setting CellVariable values

> 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 tis

Re: Question regarding Boundary Condition Implementation

You're over-complicating things trying to have three different temperatures. There's one temperature in three different domains, with different material properties in each domain. FiPy (and physics) takes care of matching fluxes for you at the internal boundaries. The changes I made are at ht

Re: Setting CellVariable values

Replies inline On Mon, Apr 8, 2019 at 7:30 PM Guyer, Jonathan E. Dr. (Fed) via fipy < fipy@nist.gov> wrote: > > > > 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   4   5   6   7   8   9   10   >