Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

changes to gmshImport.py caused --inline problems #316

Closed
guyer opened this issue Sep 19, 2014 · 2 comments
Closed

changes to gmshImport.py caused --inline problems #316

guyer opened this issue Sep 19, 2014 · 2 comments

Comments

@guyer
Copy link
Member

@guyer guyer commented Sep 19, 2014

r5209 has induced [http://build.cmi.kent.edu:8010/builders/Mac_OS_X%7Etrunk%7Efull/builds/21/steps/trial_4/logs/problems five --inline failures]

The problem is visible in this 3 cell reduction of examples/diffusion/steadyState/otherMeshes/prism.py

from fipy import *

valueLeft = 0.
valueRight = 1.

mesh = GmshGrid3D(dx=1, dy=1, dz=1, nx=3, ny=1, nz=1)

var = CellVariable(name = "solution variable",
mesh = mesh,
value = valueLeft)

exteriorFaces = mesh.exteriorFaces
xFace = mesh.faceCenters[0]

var.constrain(valueLeft, exteriorFaces & (xFace ** 2 < 0.000000000000001))
var.constrain(valueRight, exteriorFaces & ((xFace - 3) ** 2 < 0.000000000000001))

DiffusionTerm().solve(var)

print var

Normal (Python) output:

[ 0.16666667  0.5         0.83333333]

--inline output:

[ 0.25  0.25  0.75]

The problem is traceable to a discrepancy in the [trunk/fipy/terms/abstractDiffusionTerm.py@5211#L350 divergence calculation on constraints]

Imported from trac ticket #438, created by guyer on 04-12-2012 at 11:35, last modified: 04-13-2012 at 09:07

@guyer
Copy link
Member Author

@guyer guyer commented Sep 19, 2014

Replying to [guyer](issue #316):

The problem is traceable to a discrepancy in the [trunk/fipy/terms/abstractDiffusionTerm.py@5211#L350 divergence calculation on constraints]

This is further isolated to trunk/fipy/variables/addOverFacesVariable.py@5211#L58, where ids is C_CONTIGUOUS in r5160 and F_CONTIGUOUS in r5209.

In trunk/fipy/meshes/gmshImport.py@5160#L795, the call to formatForFiPy does both a swapaxes() and a [::-1] reversal, producing an array which is neither C_CONTIGUOUS nor F_CONTIGUOUS. A later call to MA.masked_values() produces a C_CONTIGUOUS array.

The reversal of cellFaceIDs caused problems and was removed in r5209, but the result is an F_CONTIGUOUS array, which remains F_CONTIGUOUS after MA.masked_values(), which our weave code can't handle. The solution is to force this array to be C_CONTIGUOUS on construction.

Trac comment by guyer on 04-12-2012 at 11:43

@guyer
Copy link
Member Author

@guyer guyer commented Sep 19, 2014

Fixed with r5213

Trac comment by guyer on 04-13-2012 at 09:07

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants