Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Shib Ganguli
@dst_faculty_twitter
@leouieda Many thanks for your reply. Have emailed you regarding this.
sylvan messenger
@sylvanmessnger_twitter
Hi, i wanted to use your seismic.wave psv code, but instead of the 3 padding areas + free surface at the top i want to have 4 padding areas. Therefore i tried to change the code and see how you did it. But i can not think of a way to see how the builtin function from fatiando.seismic._wavefd : _apply_damping() is written. Is there some way to look at the code of this function ?
Santiago Soler
@santisoler
Hi @sylvanmessnger_twitter. All Fatiando a Terra source code is available online on different GitHub repositories: https://github.com/fatiando/
They are all released under open-source licenses, so feel free to download them, study them, modify them and even share those modifications.
The code for fatiando.seisimic_wavefd is part of the deprecated fatiando package, although you can still use it if you want to. Specifically, the fatiando.seismic._apply_damping() functions is implemented on Cython in the following file: https://github.com/fatiando/fatiando/blob/master/fatiando/seismic/_wavefd.pyx
sylvan messenger
@sylvanmessnger_twitter
thank you @santisoler .
I looked a bit at github and in my fatiando folder and only found the _wavefd.pyd but wasn´t able to open it.
You mentioned it´s part of the deprecated fatiando package, is there another one ?
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:
Mark Wieczorek
@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:

  1. 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.
  2. We have two generic classes for dealing with spherical harmonic coefficients (SHCoeffs, and a subclass SHGravCoeffs) and global gridded data (SHGrid, SHGravGrid and SHGeoid).
  3. 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.
  4. 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.

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.
Mark Wieczorek
@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.
Mark Wieczorek
@MarkWieczorek
For earth, maybe something like constants.earth.wgs84.gm
There is an option to export to to xarray pyshtools.SHGrid.to_xarray()
Mark Wieczorek
@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?
Mark Wieczorek
@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?
Mark Wieczorek
@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.
Mark Wieczorek
@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
Mark Wieczorek
@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