fatiando/fatiando

Python tools for Geophysics | Room for general discussion, questions, and development updates

Santiago Soler

@santisoler

Does your local filename is _wavefd.pyd? The original one is named _wavefd.pyx. How are you opening it? Are you opening it from your File Manager or from a Text Editor/IDE?

You mentioned it´s part of the deprecated fatiando package, is there another one ?

@sylvanmessnger_twitter In fact there are four new packages (so far):

Verde
Pooch
Rockhound
Harmonica

Fatiando a Terra is currently undergoing through a big refactor, partially triggered by the end of life of Python 2.7. You can find more information about the current development of Fatiando a Terra on its website: https://www.fatiando.org .
@leouieda wrote a post on his personal blog explaining why we decided to subdivide the project into different packages.

sylvan messenger

@sylvanmessnger_twitter

yes my local filename is _wavefd.pyd. There is no .pyx file in there. I tried text editor(s) and inside my anaconda python prompt. It does import the package as it should be, but i just couldn´t find the source code (to modify it).

Thanks. i will look into the other packages.

Santiago Soler

@santisoler

@sylvanmessnger_twitter Ok. The .pyd files windows dll files created when the the Cython .pyx are compiled.
In order to modify the sources files you should clone the GitHub fatiando repository:

git clone https://github.com/fatiando/fatiando

Git will download the repository on your current directory. There you will find the latest version of the sources files.
Please read the documentation and the README.md.
Because the code for _wavefd.pyx is written in Cython, you must compile them after any modification. Otherwise you'll run the previous compiled version without any new modification.

Leonardo Uieda

@leouieda

@sylvanmessnger_twitter yep, @santisoler is right. The pyd file is a compiled binary file generated when we package fatiando for distribution. The Cython setup is a bit complex: the Cython code gets transformed into C which is compiled into a binary Python library which gets imported in wavefd. Changing the code would involve changing the Cython code, regenerating the C, and recompiling the library. Take a look at the wavefd branch on Github which has a new version of the code we were working on. It uses the numba library instead of Cython so the whole compilation step is taken out and done automatically: https://github.com/fatiando/fatiando/tree/wavefd/fatiando/seismic/wavefd It also has a much nicer class interface instead of the clumsy functions in the 0.5 implementation.

sylvan messenger

@sylvanmessnger_twitter

thank you very much. I will look into it this weekend.

Leonardo Uieda

@leouieda

🚨 Verde 1.2.0 is out! 🚨
Includes bug fixes and new features: cross-validated Spline, longitude handling, reading Surfer grids, new tutorials, and more. See what's new at https://www.fatiando.org/verde/latest/changes.html#version-1-2-0

Charles Rudder

@clrudder

Is there a straight forward way to force the Verde Spline interpolation to a buffered region? I have point data that interpolates well using the BlockReduce followed by Spline but generally ( due to the way the data are collected) never reaches the edges of the AOI im using and the interpolation doesnt fill the AOI polygon. i suppose I can modify the region and expand my interpolation area accordingly??

Leonardo Uieda

@leouieda

Hi @clrudder, let me see if I understand that correctly: you want to generate a grid that extends beyond the region where you have data. Is that correct? If so, the .grid method uses the region of the data by default but you can always pass in region=[west, east, south, north] to .grid to get interpolated values on any desired region (see here). See also the verde.pad_region (here) and verde.get_region (here) functions that are convenient in these situations.

Charles Rudder

@clrudder

thank you. Sounds like i was on the right path but I suspect the verde.pad_region is a better solution... Cheers

Leonardo Uieda

@leouieda

Glad to help :-) Let us know if there is anything you find missing in the library. We're always looking for ways to expand.

Daniel Shapero

@danshapero

Finally got around to adding a progress bar for pooch, just opened up the PR

Also you can add icepack: https://icepack.github.io as a project using a pooch

Leonardo Uieda

@leouieda

Thanks @danshapero! I'll have a look at the code as soon as I can. For reference this is fatiando/pooch#97

Leonardo Uieda

@leouieda

Hi @/all we're trying out a new Slack group that would replace our mailing list and Gitter. You can sign up for it through this invite link: https://join.slack.com/t/fatiando/shared_invite/enQtNzI5ODk4MDU3MzYzLTMyN2EwZjYwNTQzNWI4YzUzOGQyYjNkZTJlMmFiNDI2OThkYjMxNWQwNmZkNTc1ZDUxNmM2Mjg2Yjg4YTBlZjc

Later on we'll create a sign up form on the website.

Hope to see you there! :rocket:

markwieczorek

@MarkWieczorek

Hey there. I'm curious if there is any interest in coordinating parts of this project with pyshtools. There are a few things that might be beneficial to both of us:

We have aconstants module that defines a lot of basic shape/gravity parameters of the planets, and I would be more than happy to add more Earth values if necessary.
We have two generic classes for dealing with spherical harmonic coefficients (SHCoeffs, and a subclass SHGravCoeffs) and global gridded data (SHGrid, SHGravGrid and SHGeoid).
There are basic plotting routines for grids and power spectra, and as soon as gmt6 and py-gmt is released, I will add map projections.
There is some code for creating global gravity disturbances in spherical coordinates, normal gravity, gravity gradients, and the Bouguer correction (I think you are using cartesian approximations for the Bouguer correction).

In an ideal case, I could see removing all the gravity stuff from my code, and putting it into a separate module to import.

A few things that I have wanted to do, that you already started working on, was to add support for different ellipsoids, as well as simple routines to calculate Bouguer and isostatic anomalies.

In any case, let me know if this interests anyone.

Here's a notebook showing what is implemented: https://shtools.oca.eu/shtools/public/pages/mydoc/notebooks/Introduction-3.html

Leonardo Uieda

@leouieda

@MarkWieczorek I've actually been looking at the SHTools classes and constants and meant to write you but never found the time. I agree that we should work together on this! I have some student projects coming up that will make use of SHTools so it will be a good time to explore some of the functionality more closely.

I saw the constants module and this is probably something we should coordinate. Maybe migrating everything to a single package or even making a new one with planetary constants (it would be a simple tool with no heavy dependencies and thus easy to adopt).

I really like the way we're handling ellipsoids in Harmonica: https://www.fatiando.org/harmonica/dev/api/generated/harmonica.ReferenceEllipsoid.html This is something that could easily be adopted by pyshtools when we have our first release. Harmonica is pure Python so adding it as dependency shouldn't be much trouble. I'd also be open to stripping this out into a separate package to make it easier for everyone.

markwieczorek

@MarkWieczorek

I think that it might be a good idea to make a standalone package for planetary constants (even if it would only be a couple of files). I guess the key would be to first come up with an naming convention and directory structure that makes sense.

Leonardo Uieda

@leouieda

I like the API for the coefficients but I'd rather use xarray for the grids. Have you had a look at this package? I think it would cut a lot of the SHGrid code so you'd only have to implement/maintain the spherical harmonic expansion code. xarray handles plotting, saving, reading, etc and is really handy for computations.

markwieczorek

@MarkWieczorek

For earth, maybe something like constants.earth.wgs84.gm

There is an option to export to to xarray pyshtools.SHGrid.to_xarray()

markwieczorek

@MarkWieczorek

Perhaps I could make better use of xarray internally, but I don't think that it would add more functionality (it might just be cleaner).

Leonardo Uieda

@leouieda

Perhaps I could make better use of xarray internally, but I don't think that it would add more functionality (it might just be cleaner).

My thought was more that the SHGrid class could be almost entirely replaced with xarray.DataArray. The only functionally missing seems to be the sh expansion

I think that it might be a good idea to make a standalone package for planetary constants (even if it would only be a couple of files). I guess the key would be to first come up with an naming convention and directory structure that makes sense.

Now that I think about it, this is tightly integrated with the ellipsoids so it might make sense to have a package for defining ellipsoids with all constants. We could use it in Harmonica and in pyshtools.

@santisoler any thoughts on this?

markwieczorek

@MarkWieczorek

I'll look into basing SHGrid on an xarray DataArray. I think that this makes sense, but given that there are several types of grids (complex, real, GLQ, DH), it will be non-trivial (but not hard...), and it might be difficult to keep backwards compatibility. It also might make sense to use an xarray DataSet for the expanded components of the gravity field (i.e., 3 components, total field, potential, and tensor components). In any case, in the meantime, this won't have much impact on the end user.

Leonardo Uieda

@leouieda

Oh yeah, this would be a huge change and definitely break compatibility. I thought it might be something to keep in mind for the future of the package. But would you be interested in a package that implements our ellipsoid mechanics with several planetary parameters included?

markwieczorek

@MarkWieczorek

I would be interested in helping with a planetary constants package. My preference would be to make this a stand alone project: I would then just strip the existing code from my project and import it. Ideally, this would (eventually) develop into something bigger than just gravity/ellipsoid constants. I can see lots of things being added that would be useful to the community, from astronomical/orbital parameters to mineral densities and elastic constants.

markwieczorek

@MarkWieczorek

For info: I've just added better support of xarray DataArrays and DataSets to pyshtools: SHTOOLS/SHTOOLS#197 In the future, it is probable that I will base of the Grid classes off of xarray DataArrays, but this will have to wait.

Leonardo Uieda

@leouieda

Ideally, this would (eventually) develop into something bigger than just gravity/ellipsoid constants.

That is a good point! I do think this can be something useful for other projects. I'm pretty much convinced that this should be done. Just waiting to see if anyone has objections.

In the future, it is probable that I will base of the Grid classes off of xarray DataArrays, but this will have to wait.

This might be a useful reference for doing that: http://xarray.pydata.org/en/stable/internals.html#extending-xarray It could live parallel to the current SHGrid class while it's being deprecated

Leonardo Uieda

@leouieda

By the way, we have a new Slack channel for these discussions. Don't know if it'll be better than gitter and I'll still monitor gitter. If you're interested, here is the invitation link https://join.slack.com/t/fatiando/shared_invite/enQtNzY4NDQ3ODQwNDk4LTc5MTU5OWNkNTczMDY4NjcyNjcyZTU0Y2I3MDQ0NWUwMmEzMTBkNmVjNTExMGZkMjA0YzM1OGYyMzZlMDk3YTU

markwieczorek

@MarkWieczorek

Thanks. for the constants, I guess we just need to come up with a name, and then I can create the repo. I'm at a loss of ideas.

Thanks for the slack invite. An alternative that is just getting started is keybase, but it might not have all the functionality of slack yet.

Leonardo Uieda

@leouieda

Attention Pooch users: We're dropping Python 2.7 support for the next release (see fatiando/pooch#100). Any objections? We can also wait for 1 more release.

Leonardo Uieda

@leouieda

Here are some tentative plans for the next couple of Pooch releases. I'd appreciate some feedback: fatiando/pooch#105

Leonardo Uieda

@leouieda

Pooch v0.6.0 is out! This will be the last version to support Python 2.7 https://www.fatiando.org/pooch/v0.6.0/changes.html#version-0-6-0

Jeremy Menzer

@jgmenzer

Hey All, a question for the older fatiando regarding the PrismRelief function. I want to double check I have the reference level set correctly, as I am trying to build a model of equivalently a half sphere (concave down). With the top of the model at 0.5 m below ground surface and the bottom of the half sphere at 0.65 m below ground surface. To do this properly my ref value would be 0.5 and all z values of nodes would be greater than 0.5 correct? I add a quick sketch.

Leonardo Uieda

@leouieda

Hi @jgmenzer that sounds right to me. The zref is a flat surface (like 0 elevation for topography) so this makes sense to me.

Jeremy Menzer

@jgmenzer

Hey @leouieda, thanks for confirming, that's what I was thinking but you never know.

Felipe LC

@FelipeLC_gitlab

Hello all, I'm newbie with a fresh installation of Verde. After install like recommended in the official page, I downloaded two examples (distance_mask and scipygridder) and I tried to run them. Sadly I received the same error in these attempts: "TypeError: _pcolorargs() got an unexpected keyword argument 'allmatch' ".

I'm running python 3.8, but I don't know if here is the best place to get help with this issue. I'll be grateful if you can guide me. Thanks !!

Where communities thrive

People

Repo info

Activity