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.

Sign up for GitHub

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

Jump to bottom

import issue when using underworld #98

Open
NengLu opened this issue Nov 3, 2021 · 18 comments
Open

import issue when using underworld #98

NengLu opened this issue Nov 3, 2021 · 18 comments

Comments

@NengLu
Copy link

NengLu commented Nov 3, 2021

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
Copy link
Contributor

rbeucher commented Nov 8, 2021

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

@rbeucher rbeucher transferred this issue from underworldcode/quagmire Nov 8, 2021
@NengLu
Copy link
Author

NengLu commented Nov 8, 2021 •
edited
Loading

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

underworldcode/underworld2#587

@NengLu
Copy link
Author

NengLu commented Nov 9, 2021

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
Copy link
Author

NengLu commented Nov 15, 2021

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

@lmoresi
Copy link
Member

lmoresi commented Nov 15, 2021 via email

@NengLu
Copy link
Author

NengLu commented Nov 17, 2021

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
Copy link
Member

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
Copy link
Member

lmoresi commented Nov 17, 2021 via email

@julesghub
Copy link
Member

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.

@lmoresi
Copy link
Member

lmoresi commented Nov 17, 2021 via email

@rbeucher rbeucher mentioned this issue Jan 5, 2022
Closed
@rbeucher
Copy link
Contributor

rbeucher commented Jan 5, 2022 •
edited
Loading

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
Copy link
Contributor

rbeucher commented Jan 5, 2022 •
edited
Loading

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
Copy link
Contributor

rbeucher commented Jan 5, 2022

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

@rbeucher
Copy link
Contributor

rbeucher commented Jan 5, 2022

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

@lmoresi
Copy link
Member

lmoresi commented Jan 5, 2022

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
Copy link
Contributor

rbeucher commented Jan 5, 2022

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

@rbeucher
Copy link
Contributor

rbeucher commented Jan 5, 2022 •
edited
Loading

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)

image

@rbeucher
Copy link
Contributor

rbeucher commented Jan 6, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@rbeucher @lmoresi @julesghub @NengLu