Closed bflinchum closed 2 years ago
Way of installation: manual compilation from source ( I changed to V1.1.0 to match what can be installed via conda) Downloaded here: https://github.com/gimli-org/gimli/tree/v1.1.0. I would have loved to install via conda but don't have it on this computer and fear it would mess a lot of stuff up.
First, congratulation to sucessfully compile the code from the source! Did you experience any difficulties or are there any points where we should improve the installation instructions?
As to conda: if you install Miniconda locally within your home directory, you should not mess anything up, particularly when working with environments. Maybe you can try installing with conda as an alternative way.
Hey @halbmy, Yes, there are some compilation errors. If you download the master branch it won't compile on mac.
Just some background. I use macports to manage and install all of my packages not brew. Initially when compiling (before the conda release) the trick was getting boost installed correctly. It took me a while to figure out but now that I have it it's not too bad to compile. To solve the boost issue I ended up adding a soft link to the build directory. So here are the steps I follow to compile the code:
#Create a soft link to the boost libraries in the build directory
ln -s /opt/local/include/boost boost
#Paths are do libraries I located on my computer (opt/local is the macports directory)
cmake ../ -DPYTHON_EXECUTABLE="/opt/local/bin/python3" -DPYTHON_INCLUDE_DIR="/opt/local/Library/Frameworks/Python.framework/Versions/3.7/include/python3.7m" -DPYTHON_LIBRARY="/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib/libpython3.7.dylib" -DPY_Numpy="/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/numpy"
make -j 8
make pygimli
I know that you must have a solution to the problem because if I download the version 1.1.0 that is under versions everything compiles fine. However, if I download the current master branch and follow the same steps I get an error on the "make pygimli". I know that this error has been flagged because there is a comment written into the .cpp file!:
// FW: Caused problems during Mac build.
I am not exactly sure what a "type error" is. If this information is helpful and you want more please let me know. I can copy all of the output from my terminal in here so you can see warnings and things too.
[ 83%] Building CXX object core/python/CMakeFiles/_pygimli_.dir/generated/custom_rvalue.cpp.o
/Users/bflinch/PyGIMLi/V1p1a/build/core/python/generated/custom_rvalue.cpp:50:17: error: call to 'type' is ambiguous
<< GIMLI::type(ValueType(0)) << ")" << typeid(ValueType).name())
^~~~~~~~~~~
/Users/bflinch/PyGIMLi/V1p1a/build/core/python/generated/custom_rvalue.cpp:34:52: note: expanded from macro '__DC'
#define __DC(str) if (GIMLI::deepDebug() > 0) __MS(str)
^~~
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:127:41: note: expanded from macro '__MS'
#define __MS(str) std::cout << "*** " <<str << " " << WHERE << std::endl;
^~~
/Users/bflinch/PyGIMLi/V1p1a/build/core/python/generated/custom_rvalue.cpp:340:16: note: in instantiation of function template specialization
'r_values_impl::checkConvertibleSequenz<unsigned long>' requested here
return checkConvertibleSequenz<GIMLI::Index>(obj);
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:409:20: note: candidate function
inline std::string type(const bool & var) { return "bool"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:410:20: note: candidate function
inline std::string type(const int32 & var) { return "int32"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:411:20: note: candidate function
inline std::string type(const int64 & var) { return "int64"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:412:20: note: candidate function
inline std::string type(const uint32 & var) { return "uint32"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:413:20: note: candidate function
inline std::string type(const uint64 & var) { return "uint64"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:416:20: note: candidate function
inline std::string type(const float & var) { return "float"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:417:20: note: candidate function
inline std::string type(const double & var) { return "double"; }
^
/Users/bflinch/PyGIMLi/V1p1a/build/core/python/generated/custom_rvalue.cpp:50:17: error: call to 'type' is ambiguous
<< GIMLI::type(ValueType(0)) << ")" << typeid(ValueType).name())
^~~~~~~~~~~
/Users/bflinch/PyGIMLi/V1p1a/build/core/python/generated/custom_rvalue.cpp:34:52: note: expanded from macro '__DC'
#define __DC(str) if (GIMLI::deepDebug() > 0) __MS(str)
^~~
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:127:41: note: expanded from macro '__MS'
#define __MS(str) std::cout << "*** " <<str << " " << WHERE << std::endl;
^~~
/Users/bflinch/PyGIMLi/V1p1a/build/core/python/generated/custom_rvalue.cpp:368:16: note: in instantiation of function template specialization
'r_values_impl::checkConvertibleSequenz<long>' requested here
return checkConvertibleSequenz<GIMLI::SIndex>(obj);
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:409:20: note: candidate function
inline std::string type(const bool & var) { return "bool"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:410:20: note: candidate function
inline std::string type(const int32 & var) { return "int32"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:411:20: note: candidate function
inline std::string type(const int64 & var) { return "int64"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:412:20: note: candidate function
inline std::string type(const uint32 & var) { return "uint32"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:413:20: note: candidate function
inline std::string type(const uint64 & var) { return "uint64"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:416:20: note: candidate function
inline std::string type(const float & var) { return "float"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:417:20: note: candidate function
inline std::string type(const double & var) { return "double"; }
^
/Users/bflinch/PyGIMLi/V1p1a/build/core/python/generated/custom_rvalue.cpp:558:13: error: call to 'type' is ambiguous
GIMLI::type(ValueType(0))) // FW: Caused problems during Mac build
^~~~~~~~~~~
/Users/bflinch/PyGIMLi/V1p1a/build/core/python/generated/custom_rvalue.cpp:34:52: note: expanded from macro '__DC'
#define __DC(str) if (GIMLI::deepDebug() > 0) __MS(str)
^~~
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:127:41: note: expanded from macro '__MS'
#define __MS(str) std::cout << "*** " <<str << " " << WHERE << std::endl;
^~~
/Users/bflinch/PyGIMLi/V1p1a/build/core/python/generated/custom_rvalue.cpp:644:16: note: in instantiation of function template specialization
'r_values_impl::checkConvertibleNumpyScalar<long>' requested here
return checkConvertibleNumpyScalar< GIMLI::SIndex >(obj);
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:409:20: note: candidate function
inline std::string type(const bool & var) { return "bool"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:410:20: note: candidate function
inline std::string type(const int32 & var) { return "int32"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:411:20: note: candidate function
inline std::string type(const int64 & var) { return "int64"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:412:20: note: candidate function
inline std::string type(const uint32 & var) { return "uint32"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:413:20: note: candidate function
inline std::string type(const uint64 & var) { return "uint64"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:416:20: note: candidate function
inline std::string type(const float & var) { return "float"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:417:20: note: candidate function
inline std::string type(const double & var) { return "double"; }
^
/Users/bflinch/PyGIMLi/V1p1a/build/core/python/generated/custom_rvalue.cpp:558:13: error: call to 'type' is ambiguous
GIMLI::type(ValueType(0))) // FW: Caused problems during Mac build
^~~~~~~~~~~
/Users/bflinch/PyGIMLi/V1p1a/build/core/python/generated/custom_rvalue.cpp:34:52: note: expanded from macro '__DC'
#define __DC(str) if (GIMLI::deepDebug() > 0) __MS(str)
^~~
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:127:41: note: expanded from macro '__MS'
#define __MS(str) std::cout << "*** " <<str << " " << WHERE << std::endl;
^~~
/Users/bflinch/PyGIMLi/V1p1a/build/core/python/generated/custom_rvalue.cpp:656:16: note: in instantiation of function template specialization
'r_values_impl::checkConvertibleNumpyScalar<unsigned long>' requested here
return checkConvertibleNumpyScalar< GIMLI::Index >(obj);
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:409:20: note: candidate function
inline std::string type(const bool & var) { return "bool"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:410:20: note: candidate function
inline std::string type(const int32 & var) { return "int32"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:411:20: note: candidate function
inline std::string type(const int64 & var) { return "int64"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:412:20: note: candidate function
inline std::string type(const uint32 & var) { return "uint32"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:413:20: note: candidate function
inline std::string type(const uint64 & var) { return "uint64"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:416:20: note: candidate function
inline std::string type(const float & var) { return "float"; }
^
/Users/bflinch/PyGIMLi/V1p1a/core/src/gimli.h:417:20: note: candidate function
inline std::string type(const double & var) { return "double"; }
^
4 errors generated.
gmake[7]: *** [core/python/CMakeFiles/_pygimli_.dir/build.make:1772: core/python/CMakeFiles/_pygimli_.dir/generated/custom_rvalue.cpp.o] Error 1
gmake[6]: *** [CMakeFiles/Makefile2:654: core/python/CMakeFiles/_pygimli_.dir/all] Error 2
gmake[5]: *** [CMakeFiles/Makefile2:742: core/python/CMakeFiles/pg.dir/rule] Error 2
gmake[4]: *** [Makefile:430: pg] Error 2
make[3]: *** [pgbuild] Error 2
make[2]: *** [core/python/CMakeFiles/pgbuild.dir/all] Error 2
make[1]: *** [CMakeFiles/pygimli.dir/rule] Error 2
make: *** [pygimli] Error 2
e8deec6 will hopefully fix the compilation issue.
I tried your script (needed to move the __main__
scope to the end of the file) but can't reproduce the maxIter
issue.
ra.inv.maxIter = 1
or
ra.invert(data=ra.data,mesh=mesh,lam=smoothing,zWeight=vertWeight,startModel=1./avgVel,
verbose=True, maxIter=1)
work both for me as supposed (on the dev branch). I set the verbose=True
to see the iteration counting stops at 1. For the inversion the run of at least one iteration is forced every time.
Try the keyword argument 'startModel' instead of 'startmodel' (we came from cpp and decided for camel shape as design pattern, which is sadly not always unambiguous). The inversion log info tells you which starting model is used.
To only show the ray paths, it should be sufficient to call ra.showRayPaths
with an appropriate model
argument.
Assuming ra
knows a mesh and data after one prior run, It will call the response for any model that differ from the last active known model. Same for ra.drawRayPaths
which also have the model argument.
https://www.pygimli.org/pygimliapi/_generated/pygimli.physics.traveltime.html?highlight=showraypath#pygimli.physics.traveltime.TravelTimeManager.showRayPaths
Exporting these raypaths to VTK might be possible too .. I can think about a snipped if you want them.
Hope this helps for some of your questions .. please ask if I miss some points (its a little late now to have the complete overview)
Cheers, Carsten
Here is a suggestion for ray paths from your first sensor considering some code of the refraction example in 3D and the MultiBlock object of pyvista:
#(...)
#Trace the rays through the average model:
ra = TravelTimeManager(data)
mesh = ra.createMesh(data=ra.data,paraDepth=maxDepth,paraDX=meshDx,paraMaxCellSize=maxTriArea)
matModVel = np.genfromtxt(path2Runs+'allVelocityModels.txt')
fop = pg.core.TravelTimeDijkstraModelling(mesh, ra.data)
dij = pg.core.Dijkstra(fop.createGraph(1 / matModVel[:,-1]))
arrSensors = np.array(data.sensorPositions())
import pyvista as pv
mbRays = pv.MultiBlock()
dij.setStartNode(mesh.findNearestNode(arrSensors[0,:]))
for arrSens in arrSensors:
ni = dij.shortestPathTo(mesh.findNearestNode(arrSens))
pos = mesh.positions(withSecNodes=True)[ni]
segs = np.zeros((len(pos), 3))
segs[:, 0] = pg.x(pos)
segs[:, 1] = pg.y(pos)
segs[:, 2] = pg.z(pos)
mbRays.append(pv.lines_from_points(segs,close=False))
mbRays = mbRays.combine()
pv.save_meshio(os.path.join(path2Runs,'rayShots_0.vtk'),mbRays)
Cheers, Stephan
There hasn't been any activity on this issue recently and was wondering whether the compilation or compatibility problem was solved through version 1.2. If not we should make a new issue.
As to the problem of ray paths, we should have a new look at the problem using version 1.2. I started doing that but I get confused by errors saving and loading files. I am attaching my script. If the problem persists, start from there, if not, we can close the issue. pg289.py.txt
There hasn't been any activity since a while but I guess we all have learned a lot, so I close it. Thanks @bflinchum for the input.
Problem description
Issues with the change of version. My scripts worked when I was on a different version of the code but now fail to work with version 1.1.0 (the widely distributed version).
Your environment
Operating system: Mac Python version: 3.7.9 pyGIMLi version: 1.1.0 Way of installation: manual compilation from source ( I changed to V1.1.0 to match what can be installed via conda) Downloaded here: https://github.com/gimli-org/gimli/tree/v1.1.0. I would have loved to install via conda but don't have it on this computer and fear it would mess a lot of stuff up.
Question/Bug
A while ago I updated from version 1.0 to 1.1 and had to modify my scripts. You guys helped me through this by moving me to the developers branch and provided me with some fixes to my issue: https://github.com/gimli-org/gimli/issues/235
At this stage I have had to "downgrade (?)" to version 1.1.0 because I am teaching my graduate students how to operate the code and the easiest install is through conda (thanks for that by the way!). I have a bootstrapping inversion where I re-sample all of the picks and then invert the data over and over again. At the end of the inversion I average together all of the velocities and want to trace the rays and calculate the inversion statistics on this. Previously (https://github.com/gimli-org/gimli/issues/235), you told me to just set up the inversion again with the average velocity as the starting model and set the maxIter flag = 0. There are now a few issues:
ra.invert(data=ra.data,mesh=mesh,lam=smoothing,zWeight=vertWeight,startmodel=1./avgVel, maxIter=0)
This line would give me what I wanted. But in version 1.1.0 this till runs for 20 iterations. I found a way around the maxIter flag by setting the variable self.inv.maxIter=0. Even despite this, it clearly does at least one iteration because I have done this with a starting gradient model and the result has some structure in it. My guess is that the inversion ran but the forward model has not been run through that iteration.
So my question is how do I run the forward model (get the rays, ray coverage, standard ray coverage) and update the traveltime structure (in my case the varible ra) if I know the the velocity model and have the mesh?
What I want is the following:
Here is my code:
TLV_2016_0816_picks_gimliInput.txt TLV_2016_0816_picks.txt TLV_2016_0816_topoLiDARm.txt