import issue when using underworld

[NengLu]

Hi guys, I run into an import issue and that bother me a while, would you help me check with that? if import underworld and stripy together, it will somehow get the wrong tri.simplices:

import underworld
from stripy import cartesian_meshes
minX, maxX, minY, maxY, dx, dy = 0.0, 3.0 ,0.0, 1.0, 0.015625 ,0.015625
extent_xy = [minX, maxX, minY, maxY]
tri = cartesian_meshes.square_mesh(extent_xy, dx,dy, random_scale=0.0, refinement_levels=0)
tri.simplices

The result is:

TRMESH - Fatal error!
  The first 3 nodes are collinear.
  Try reordering the data.
array([], shape=(0, 3), dtype=int64)

While import stripy alone, the tri.simplices are correct as:

array([[    0, 12544, 11005],
       [    0, 11005,   193],
       [    1, 12543, 11470],
       ...,
       [12096, 12434, 12433],
       [12209, 12398, 12397],
       [12260, 12419, 12418]])

Are there any function conflicts there in underworld and stripy or? Thanks in advance.

[rbeucher]

This is a stripy / underworld issue. Underworld 2.11 Stripy latest as of 8/11/2021

[NengLu]

Here is the link that how to install them, using conda to install stripy and compile the underworld from source code in the env.

https://github.com/underworldcode/underworld2/issues/587

[NengLu]

update: tried reinstalling stripy with 2 verisons.

1. stripy1.2.2 by $ python3 -m pip install stripy
2. stripy2.0.2 by $ conda install -c underworldcode stripy
   Still have the same issue.

[NengLu]

update: tried reinstalling stripy from source code (version 2.05b2), still have the same issue

[lmoresi]

Just to help us figure out what is going on, can you try with a non-zero value of the random scale parameter. Also, if you look at the documentation, you can access the underlying triangulation routines and have a bit more control on what is happening with stripy. https://underworldcode.github.io/stripy/2.1.0b1/SphericalMeshing/CartesianTriangulations/Ex1-Cartesian-Triangulations.html That would allow you to permute the points in response to this error and we can most certainly determine whether the error is some sort of bug in the loading of libraries. L Prof Louis ***@***.***(m) +61 4 0333 1413(us) +1 505 349 ***@***.***   From: Neng Lu ***@***.***>Date: Monday, 8 November 2021 at 11:25 amTo: underworldcode/stripy ***@***.***>Cc: Subscribed ***@***.***>Subject: [underworldcode/stripy] import issue when using underworld (Issue #98)Hi guys,I run into an import issue and that bother me a while, would you help me check with that?if import underworld and stripy together, it will somehow get the wrong tri.simplices:import underworldfrom stripy import cartesian_meshesminX, maxX, minY, maxY, dx, dy = 0.0, 3.0 ,0.0, 1.0, 0.015625 ,0.015625extent_xy = [minX, maxX, minY, maxY]tri = cartesian_meshes.square_mesh(extent_xy, dx,dy, random_scale=0.0, refinement_levels=0)tri.simplicesThe result is:TRMESH - Fatal error!  The first 3 nodes are collinear.  Try reordering the data.array([], shape=(0, 3), dtype=int64)While import stripy alone, the tri.simplices are correct as:array([[    0, 12544, 11005],       [    0, 11005,   193],       [    1, 12543, 11470],       ...,       [12096, 12434, 12433],       [12209, 12398, 12397],       [12260, 12419, 12418]])Are there any function conflicts there in underworld and stripy or? Thanks in advance.—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[NengLu]

Hi Louis, Thanks for the reply. I tried several sets of parameters and it all get the same issue. and when using function stripy.Triangulation directly as in the example also has the issue. It will get the right result when importing stripy alone, and get the error when importing stripy after underworld:

sTRMESH - Fatal error!
  The first 3 nodes are collinear.
  Try reordering the data.

It's more likely the dynamic libraries issue like Romain mentioned.

[julesghub]

Using python3.9 and trying: pip install stripy I get the following error:

Error: Rank mismatch in argument ‘lcc’ at (1) (rank-1 and scalar)
    src/srfpack.f:7391:37:

     7391 |          CALL intrc1(xs(i),ys(i),ncc,lcc,n,x,y,zdata,lst,lptr,lend,
          |                                     1
    Error: Rank mismatch in argument ‘lcc’ at (1) (rank-1 and scalar)

Using gfortran 11.2.0.

This is a stripy issue. I'll look into updating it.

[lmoresi]

Email …    From: Julian Giordani ***@***.***>Date: Wednesday, 17 November 2021 at 3:38 pmTo: underworldcode/stripy ***@***.***>Cc: Louis Moresi ***@***.***>, Mention ***@***.***>Subject: Re: [underworldcode/stripy] import issue when using underworld (Issue #98)Yes it's occurring during the build. I'm on master and I fixed the problem!I also see the fix is also on branch dev. Should we merge dev into master and make a new release?Also what client are you using with github @lmoresi, your replies to tickets are full of css jargon.—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[rbeucher]

Using python3.9 and trying: pip install stripy I get the following error:

Error: Rank mismatch in argument ‘lcc’ at (1) (rank-1 and scalar)
    src/srfpack.f:7391:37:

     7391 |          CALL intrc1(xs(i),ys(i),ncc,lcc,n,x,y,zdata,lst,lptr,lend,
          |                                     1
    Error: Rank mismatch in argument ‘lcc’ at (1) (rank-1 and scalar)

Using gfortran 11.2.0.

This is a stripy issue. I'll look into updating it.

Sorry I saw that a bit late. I fixed it on master...

[rbeucher]

OK results of my investigations for today...

x.txt and y.txt are just dumps of Neng's code when using stripy only...

What does not work:

import underworld
from stripy._tripack import trmesh
import numpy as np
x = np.loadtxt("x.txt")
y = np.loadtxt("y.txt")
trmesh(x,y)

What works (from the directory where _tripack.*.so is located)

import underworld
from _tripack import trmesh
import numpy as np
x = np.loadtxt("x.txt")
y = np.loadtxt("y.txt")
trmesh(x,y)

The difference is that in case 1 we have some extra dynamic libraries loaded...

112a113,115
> /home/romain/PROJECTS/Project_underworld_quagmire_stripy/stripy/stripy/_srfpack.cpython-310-x86_64-linux-gnu.so
> /home/romain/PROJECTS/Project_underworld_quagmire_stripy/stripy/stripy/_tripack.cpython-310-x86_64-linux-gnu.so
> /home/romain/PROJECTS/Project_underworld_quagmire_stripy/stripy/stripy/_ssrfpack.cpython-310-x86_64-linux-gnu.so
122c125
< /home/romain/PROJECTS/Project_underworld_quagmire_stripy/stripy/stripy/_tripack.cpython-310-x86_64-linux-gnu.so
---
> /home/romain/PROJECTS/Project_underworld_quagmire_stripy/stripy/stripy/_stripack.cpython-310-x86_64-linux-gnu.so

Not very helpful

My first thought was to try passing the -fPIC options when building the libraries.... No luck...

Note that we can reduce the complexity by doing from underworld.lib import _StGermain instead of the entire underworld module...

That's all for now...

Ideas? In the first case trmesh gets nothing... no values.. Might be worth looking at the memory address that get passed...

Romain

[rbeucher]

One thing that might confuse the loader is the fact that the routines have the same names in the different Fortran extensions...

[rbeucher]

Yep that is exactly what is happening... There is an ambiguity between the trmesh subroutine in stripack.f90 and tripack.f90...

[lmoresi]

That's a pity because one of the virtues of wrapping the code is that we don't have to touch the original fortran ... and hence we are never going to introduce new bugs. Is there a way to fix this via f2py that keeps the original code untouched, or do we need a super-grep intervention ?

[rbeucher]

I don't know yet. I will investigate. I agree we shouldn't have to touch the Fortran code

[rbeucher]

I'll keep documenting the debugging process...sorry if I'm spamming everyone...

So

What works (from the directory where _tripack.*.so is located)

import underworld
import _tripack
import numpy as np
x = np.loadtxt("x.txt")
y = np.loadtxt("y.txt")
_tripack.trmesh(x,y)

Also works:

import underworld
import _tripack
import _stripack
import numpy as np
x = np.loadtxt("x.txt")
y = np.loadtxt("y.txt")
_tripack.trmesh(x,y)

Does not work and throws an sTRMESH error (so the wrong routine gets called). I think its a fortran wrapping issue...: And the reason is that stripack and tripack both have a trmesh routine...

import underworld
import _stripack
import _tripack
import numpy as np
x = np.loadtxt("x.txt")
y = np.loadtxt("y.txt")
_tripack.trmesh(x,y)

[rbeucher]

I have tried to reproduce the issue with a package that is not Underworld but has Swig generated so files... No luck...Stripy is doing things properly. Changing the name of the routine does not help...

The issue only occur when importing Underworld before the stripy submodules...And it only appears when we load strimesh before trimesh... f2py generates C bindings for TRMESH (tri and strimesh) that have distinct signatures so I don't understand what is going on...

Somehow UW messes up the way the interpreter loads the f2py generated modules in stripy... It's really hard to isolate the pb.. because the UW swig modules reference each other etc... I have tried to create simple modules but can't reproduce the issue.

The fact that we had a very similar issue with an older version of Badlands makes me believe that the pb comes from UW...

Something to revisit I suppose. Running out of ideas....