# Fatiando Community Calls 2020

## About

📱 **Join the video call:** https://meet.jit.si/fatiando/community-call

📜 **Meeting notes:** https://hackmd.io/@fatiando/community-calls-2020

🎥 **YouTube channel:** https://www.youtube.com/fatiandoorg

📅 **Shared calendar:** http://calendar.fatiando.org

🗄️ **Notes are archived at:** https://github.com/fatiando/meeting-notes

> **IMPORTANT**: Everyone is required to follow our
> [Code of Conduct](https://github.com/fatiando/contributing/blob/master/CODE_OF_CONDUCT.md)
> when participating in the Fatiando community. Please review it carefully.

Community calls are **open to everyone**!
Join us if you're interested in the project,
want to find out more,
or just want to chat with fellow coding geoscientists.

Calls happen **monthly**, usually on a Thursday around
the 15th of every month.
The time alternates between 16:00 UTC and 19:00 UTC.
Check below for the date and time of the next one.

See you online!

**Everyone is encouraged to edit the notes below.**

--------------------------------------------------------------

### **Notes for 2021 meetings:** https://hackmd.io/@fatiando/community-calls-2021

--------------------------------------------------------------

## 2020-12-17

**Time:** 16:00 (UTC)

**Youtube recording:** https://youtu.be/eIfjBEbi1r4

**Participants** (please add your name)

* Leonardo Uieda
* Santiago Soler
* Agustina Pesce
* Diana
* Mariana
* Isamar

**Quick updates**

* Pooch v1.3.0
* Starting to unify classes in Boule
* Santiago is resuming the work on the prism layer for Harmonica with Lorenzo

**Longer discussion**

* New discussion boards on GitHub:
* Example on on Boule (created to see what it offers) https://github.com/fatiando/boule/discussions
* Should we use them for questions and other things?
* Which topics?
* For questions, it seems better than issues (can mark a solution to the question). But not sure for project discussions in general.
* One drawback is that this is repository specific and we have many projects. A single dicusssion board might be a better solution (like a Discourse forum).
* Could be done with a Discussion board in a separate repo, like `contributing`
* If we're using, it would be nice to have:
* A standard welcome post across the repos
* Some way of pointing people there instead of issues?
* Could be a good place to post use cases
* Live in `contributing`/`community`
* Rename `contributing` to something else:
* `community` it is
* Change some scripts that deploy from CI
* Fix links in the website and project docs
* Scope of Harmonica:
* What niche are we trying to fit that is currently vacant?
* SimPEG and PyGMIli do physical property distribution
* Not a lot of tools for processing: gridding, transformations (FFT-based), corrections, etc
* Or non-linear potential field inversion
* Other things like Euler deconvolution
* What don't we want to include in Harmonica? (already exists, is not in best practices, etc)
* Generic inversion things ([Pylops](https://pylops.readthedocs.io/en/latest/) can be this)
* Mesh generation
* Plotting
* Toy examples
* What do we want Harmonica to be able to do (at least initially)?
* Processing with equivalent layer and FFT
* General corrections
* Euler deconvolution, non-linear inversions
* Forward modelling

## 2020-11-12

**Time:** 16:00 (UTC)

**Youtube recording:** Leo forgot to press record... 😔

**Participants** (please add your name)

* Leo Uieda
* Santi Soler
* Federico Esteban
* Agustina Pesce

**Quick updates**

* Status of maintenance tasks: https://github.com/fatiando/maintenance/issues
* New URL to simplify search of tasks across our repos: http://good-first-issues.fatiando.org
* :+1: or :-1: to update our Code of Conduct: https://github.com/fatiando/contributing/issues/22
* A bunch of new PRs on Boule by Chris and Mariana :tada:
* New Pratt Isostasy PR on Harmonica by Andrea :tada:

**Longer discussion**

* Think about sumitting a mentoring project to [Outreachy](https://www.outreachy.org/) in the future
* Open an issue in `contributing` or `maintenance` to organize and keep track
* Harmonica
* Optimization and design of forward modelling ([#205](https://github.com/fatiando/harmonica/pull/205))
* Rockhound
* Host already processed data (as optimized and compressed netCDF files or csv files) on Zenodo (specially for big datasets).
* Rockhound will only have to download them, no more processing them at runtime.
* Store the code to produce these datasets on `rockhound-data` as notebooks or `.py` files.
* Drop Bedmap from Rockhound.
* Make a strong requirement for new additions to Rockhound: data must have a LICENSE.

## 2020-10-15

**Date:** 2020/10/15 - 16:00 (UTC)

**Youtube recording:** https://youtu.be/gsYKW7XNzzw

**Participants** (please add your name)

* Leo Uieda
* Andrea Balza
* Santiago Soler
* Agustina Pesce

**Quick updates**

* Working with Geolatinas for training and getting them involved in the project :rocket:
* Trying out the new [Nox](https://nox.thea.codes/) tool to automate creating virtual envs and running tests, static checks, building docs, etc. It's pretty nice and simplifies the CI scripts quite a bit. Plus, we can run tests on all Python versions (including with or without optional dependencies) on our computers with `nox -s test` (using pip) or `nox -s test_conda` (using conda). See https://github.com/fatiando/boule/pull/59

**Longer discussion**

* Verde
* Deprecate the `scatter` method for gridders. It's kind of useless.
* Could we use [dask-ml](https://ml.dask.org/modules/generated/dask_ml.linear_model.LinearRegression.html#dask_ml.linear_model.LinearRegression) for distributed fitting?
* Documentation needs to be reorganized following guidelines here: https://documentation.divio.com/ (numpy recently got a grant to do this to their docs)
* Would be good to come up with a general structure (which sections we think should exist and what should go in each)
* We can work on a separate branch and make incremental pull requests there. Once that's done, we can merge it into `master`
* Opened new [fatiando/maintenance](https://github.com/fatiando/maintenance) repository to keep track of maintenance tasks needed on more than one repository.
* We are planning to organize a Fatiando Maintenance Week (probably some time in November) to tackle these tasks.
* Things that we might want to implement:
* Replacing Travis and Azure with GitHub Actions
* Should we keep Stickler and Codecov?
* Use `nox`
* Replace `versioneer` with `setuptools-scm` (a more modern and supported tool).
* Updating packaging: use `pyproject.toml` instead of `setup.py`. This is a new standard for Python ([PEP517](https://www.python.org/dev/peps/pep-0517/)) that is based around the [pypa/build](https://github.com/pypa/build) tool instead.
* Implement Release Drafter.
* Move sample datasets to a single repository (Rockhound sounds a good place).
* Add deprecation warnings (on >=1.0.0 libraries) for features that will be deprecated on next major release.
* Setup Calendar on Slack to schedule reminders of the next Fatiando Community Call.

## 2020-09-17

**Date:** 2020/09/17 - 19:00 (UTC)

**Youtube recording:** https://youtu.be/eEjRNGLibGo

**Participants:**

* Leo Uieda
* Santiago Soler
* Agustina Pesce

**Quick updates**

* **Next meeting date:**
* Alternate late and early meetings (eg 16:00 and 19:00 UTC)?
* Next meeting: October 15 at 16:00 UTC

**Longer discussion**

* Prep for [Hacktoberfest 2020](https://hacktoberfest.digitalocean.com/?utm_medium=email&utm_source=hacktoberfest&utm_campaign=preptember_&utm_content=participants#maintainers):
* Curate issues on projects tagged with `hacktoberfest`
* Choose short self-contained tasks
* Add an example to a docstring or gallery
* Tweak explanation in the docs
* Add a small feature or change to an existing function
* Fix a typo
* Pratt isostasy (check if it's not too big)
* CI or general maintenance (target the coders)
* Add simple models to Rockhound (things that are straight forward to load)
* If we can, get a link to all issues with the tag to share
* List all open issues with `hacktoberfest` label: https://github.com/search?q=org%3Afatiando+label%3Ahacktoberfest+is%3Aopen+is%3Aissue
* Leo can create a URL for this: http://hacktoberfest.fatiando.org
* Try to narrow the search to all non-assigned issues
* Promote on Twitter, LinkedIn, Swung?
* Add a note to fatiando.org?
* Agustina can send to Geolatinas
* See if the geophysics womens group in Brazil is intersted as well
* Been reading [Hypermodern Python](https://cjolowicz.github.io/posts/hypermodern-python-01-setup/). There are a lot of new tools that could make our dev work easier:
* Ditch pylint
* It's constantly complaining and a bit slow
* Not sure it really contributes a lot
* There are a lot of flake8 plugins that could do the job
* They are much faster
* Use [nox](https://nox.thea.codes/) to manage testing and environments
* Nox automatically creates virtual environments (even with conda) and runs tests on all specified configurations.
* Can run on multiple Python versions locally
* Use the exact same setup on CI (so wouldn't need the `environment.yml` file even)
* Replace `versioneer` with `setuptools_scm`.
* The version string is more compliant
* Use as a build dependency instead of including the versioneer source in the repo (haven't updated it in many years)
* Tool that is actually being supported
* Copy whatever [MetPy](https://github.com/Unidata/MetPy) does
* Need some issues for these in one project first. Then we port to another one.
* Have a central repo for maintenance tasks. We can open these issues that apply to all projects there instead and link back from the PRs.
* Could we use an existing one?
* [`fatiando/contributing`](https://github.com/fatiando/contributing) would be good
* TODO: add a section to the `contributing` repo README about doing this
* Migrate projects to GitHub Actions:
* Pooch is completely run on Actions now
* Much faster builds and easier to configure than Azure or Travis
* Workflows are all defined in `fatiando/pooch` with some long bash code (for deploying the docs for example)
* Can be simplified by creating [composite steps](https://docs.github.com/en/actions/creating-actions/creating-a-composite-run-steps-action) in `fatiando/continuous-integration` that are shared with other projects
* Should do this first before adopting in other projects
* Once done, we can remove the scripts for Travis and Azure
* How to do this:
* Create the composite steps in `continuous-integration` master branch
* Use it in Pooch to test that it works
* Make a release on `continuous-integration`
* Copy what's in Pooch to other projects
* Raise awerness of lack of diversity on Fatiando
* Fatiando projects welcome every contribution, while the [Code of Conduct](https://github.com/fatiando/contributing/blob/master/CODE_OF_CONDUCT.md) creates a nice environment for every contributor and user, regardless _" of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation"_.
* Nevertheless we still lack of diversity.
* Would be nice to start thinking new strategies to invite new contributors from underrepresented social groups.
* Actively work with Geolatinas to build bridges
* Agustina will bring this up in their next meeting
* Maybe we can have a workshop for them
* Agustina will ask what they need/want and how we can work together
* Promote our `good-first-issue`s through twitter, the fatiando website (in the contributing section), ping people maybe?

## 2020-08-13

**Date:** 2020/08/13 - 19:00 (UTC)

**Youtube recording:** https://youtu.be/

**Participants:**

* Santi Soler
* Martin Bentley

**Quick updates**

* **Next meeting date:** 2020/09/17 - 19:00 UTC
* Leo is taking a break until mid September

**Longer discussion**

* Pooch
* Method to clear the cache folder ([pooch#181](https://github.com/fatiando/pooch/issues/181)). Proposed by Mark on [pooch#175](https://github.com/fatiando/pooch/issues/175).
* Clear the whole cache folder vs removing files in the registry
* Problem: unzipped files
* Clear cache folder if only contains files inside the registry. If not, warn the users and use a `force=True` flag to remove everything inside the cache.
* Harmonica: Roadmap to `v0.2.0`
* Improved EQLs (common base class, `upward` positional argument on predicting methods)
* Euclidean distance in geodetic coordinates
* Add geodetic EQL
* Remove datasets (move them to Rockhound)
* Fix attributes of datasets downloaded from ICGEM (being fixed by Nicholas on [#184](https://github.com/fatiando/harmonica/pull/184))
* Documentation page about coordinate systems
* We can leave for `v0.3.0`:
* FFT features
* Improved forward models
* Tesseroids and prisms layers
* Reduce memory consumption of EQLs
* Boule
* Spherical reference ellipsoids represented by new `Sphere` class:
* How to define normal gravity? [#50](https://github.com/fatiando/boule/issues/50)
* Rockhound
* Upload each dataset to a single Zenodo entry.
* Add Martin to Fatiando community in Zenodo.

## 2020-07-16

**YouTube recording:** https://youtu.be/GJIeDxWHaN0

**Participants:**

* Leo Uieda
* Santiago Soler
* Martin Bentley

**Quick updates**

* **Next meeting date:** 2020/08/13 - 19:00 UTC
* Request for a new tips/tricks section in Pooch docs [#188](https://github.com/fatiando/pooch/issues/188) (need a good name for this)
* New Pooch user: [histolab](https://github.com/histolab/histolab) :confetti_ball:

**Longer discussion**

* Roadmap for Boule 1.0
* Ellipsoids for all rocky planets
* `Sphere` class for normal gravity calculation (should be basic physics). Moon and some others have 0 flatenning, which breaks the normal gravity equations for ellipsoids.
* Separate normal gravity into gravitational and centrifugal parts. Need to check equations to see how to do that.
* Ask SHTools what other things they need
* [poliastro](https://docs.poliastro.space/en/stable/) (astrodynamics package) expressed [interest in using Boule as well](https://twitter.com/poliastro_py/status/1283052225921679361?s=20). Check with them what they might need that is currently missing.
* JOSS paper once that is finished. If we focus efforts, could be done relatively soon.
* Roadmap for Verde 2.0
* Create an issue and milestone
* What needs to be done? Any other major deprecations?
* Prepare PRs for all deprecations but only merge ready for the release
* Should probably wait until data are moved to RockHound
* Make a new paper (JOSS or we can try another journal)
* Opportunity for new contributors to get some credit
* Hamonica status
* What are some key missing features?
* FFT based processing with xrft needs some thought (Martin has started a prototype)
* Might be good to make an effort to get derivatives, etc, in Harmonica since this was a major feature in `fatiando`
* EQLs will have a common base class, subclass of Verde's BaseGridder. Overrides `grid`, `scatter` and `profile` methods.
* Ditch spherical EQL and replace it with geodetic EQL (after new function for Euclidean distance between points in geodetic coordinates).
* The page about coordinates is really needed at this point.
* Forward modeling of layers/interfaces (needed for topographic correction and basin/Moho inversions)
* Rockhound latest news
* Rockhound will gather all functions to fetch sample data from Fatiando ([#84](https://github.com/fatiando/rockhound/pull/84))
* Need to deprecate `verde.datasets` and `harmonica.datasets` modules.
* Deprecation in Verde should be done in v2.0
* Deprecation in Harmonica can be done right away (hurray for 0.* versions :tada:)
* Need to check if Zenodo allows download of single files from an archive. If so, we can upload all sample data to a single archive. Otherwise, we'll need separate archives for each dataset.
* Leo will look into using PyGMT in RockHound
* [NEP29](https://numpy.org/neps/nep-0029-deprecation_policy.html#nep-29-recommend-python-and-numpy-version-support-as-a-community-policy-standard) for Python and Numpy version support
* Next release of our packages would drop Python <= 3.6
* Specify minimum required numpy on all packages as well
* Would be good for Verde, Harmonica, RockHound to free up CI time.
* Pooch and Boule need to be careful because of users and tests are usually quick anyway.
* Need to make issues for this in Verde and Harmonica and then update the docs and CI builds.
* Use GitHub Actions to automate changelog generation
* Release Drafter: https://github.com/fatiando/contributing/issues/15
* **Need to be more diligent with PR titles and assign labels to PRs** (comment on issue above to discuss protocols)
* Changelog generation would basically be copying from GitHub and using a `sed` command
* Contributors and sorting of changes is automatic
* Tags: documentation; bug; maintenance; (new) feature; deprecation; (internal) enhancement
* There is still oportunity for manual curation of the changelog
* Rockhound will be our rat lab for this
* Make a section on developer guide about transitioning into a maintainer role
* Based on call discussions and https://github.com/fatiando/contributing/issues/14
* Asking people interested to step up to review PRs as a start
* Could outline 2 pathways: making PRs for code and docs work or reviewing PRs
* Leave for later discussion
* Move away from "master" on GitHub
* Could move it to "main"
* Might need to be a bit careful to replace all occurances of "master" in docs, tests, CI scripts etc.
* Start with smaller packages like Boule and then try Pooch (which might be the most troublesome).
* Once all are converted we can update the contributing and maintenace guides
* https://www.theregister.com/2020/06/15/github_replaces_master_with_main/

## 2020-06-19

**Date:** 2020/06/19 - 15:00 (UTC)

**Youtube recording:** https://youtu.be/DQwfsRXoPd0

**Participants:**

* Martin Bentley
* Dan Shapero
* Santiago Soler
* Leo Uieda

**Quick updates**

* From Transform 2020:
* Verde tutorial: https://youtu.be/-xZdNdvzm3E
* Leo and Santiago's lightning talks: https://www.youtube.com/watch?v=NtBDf7d7mwM
* Pooch is being used by SHTools and they want feedback on gravity datasets for Earth: https://github.com/SHTOOLS/SHTOOLS/pull/231

**Longer discussion**

* Should Verde transition to "spatial machine learning" more generally?
* We already have a lot of the machinery required (BlockReduce, cross-validation, etc)
* The Spline is already a wrapper for Ridge and LinearRegression
* Gridders would be kept as they are. The idea would be build some things that would make it easier to use scikit-learn without the gridder API.
* [#268](https://github.com/fatiando/verde/issues/268) and related issues would get us very close to that
* The cross-validation in particular is very useful for things that aren't gridding
* Building Jacobians for Spline and Trend could be made into scikit-learn preprocessors. In fact, there is already [PolynomialFeatures](https://scikit-learn.org/stable/modules/generated/sklearn.preprocessing.PolynomialFeatures.html) for Trend so we could make a `SplineFeatures`.
* Transition sample data into RockHound:
* Would replace the `datasets` modules in packages.
* Easier to reuse the data between packages.
* Needs to have minimal required dependencies (probably just pooch with everything else being optional)
* Boost usage of RockHound
* Packages need to be careful pinning the RockHound version for building docs. Don't want the docs changing without us noticing by unintentional upgrades.
* Data for which we have rights we can process/compress and store in Zenodo. Others we can contact original authors for permission or maybe encourage them to upload to Zenodo.
* Start migrating the datasets to Zenodo and the `fetch` functions to RockHound.
* Need a commit to Harmonica and Verde to deprecate the `datasets` modules once this is done.t

## 2020-05-15

**Date:** 2020/05/15 - 15:00 (UTC)

**Youtube recording:** https://youtu.be/6Owuk3_Rgpk

**Participants:**
- Leo Uieda
- Santiago Soler
- Agustina
- Chris
- Jesse
- Leo Miquelutti

**Quick updates**

- Leo:
* Giving a 3h Verde tutorial at [Transform 2020](https://transform2020.sched.com/): https://github.com/fatiando/transform2020
* Anyone interested in helping (monitor the chat for questions mostly)?
* New cross-validation methods in Verde.
* Bug in Pooch when running in parallel (found in scikit-image) [see this PR](https://github.com/fatiando/pooch/pull/173).
* Fixed in v1.1.1 yesterday

**Longer discussion**

- Should we remove default density from Bouguer correction in Harmonica? Forgetting to change them can lead to tricky errors (for example, leaving the water density for Mars). And in Python *explicit is better than implicit* :slightly_smiling_face:
- Might be too specific a problem so worth keeping the default values?
- Could we somehow remind the user that defaults are being used? Probably hard to do in a library but UIs should do this.
- Maybe confusion is coming from the name `density_water`. Maybe change to density below the reference.
- Decision is making it easier vs making it right.
- Compromise would be have defaults but rename arguments to above and below.
- Bouguer and atmospheric correction pull request. Trickier than it seems. https://github.com/fatiando/harmonica/pull/168
- How to organize package maintainers? Should we have a clear mechanism for becoming one and also for stepping down? What would that look like? See https://github.com/fatiando/contributing/issues/14
- Chris has experience with this for course material.
- Make a private channel on slack to discuss asking people to be maintainers. Leave it informal for now.
- How to manage more than 2 dimensions on Verde and Harmonica gridders?
- PRs in Verde to expand to 3D.
- Equivalent layers are causing problems with assumptions in Verde because the need an extra height argument.
- Solution might be to have a new base class just for Harmonica equivalent layers.
- Leo M: Bane might be working on something similar. Worth looking into this. Something with 3D splines in PyVista.
- Even if we don't do full 3D we still need the height for EQL.
- Ideally we wanted just a magic solution to not need a new base class.
- Probably doesn't exits :slightly_frowning_face:
- Create a shared `fatiando-data` package or move sample data to RockHound? A lot of our packages have sample data in `datasets` modules. But there is no reason that they couldn't share the data without depending on each other. Moving all of them to the same package would make it easier to do this. Having them in `fatiando-data` would separate the sample data (which we sometimes crop/downsample) from the real data in RockHound.
- There is a LOT of public domain data here: https://www.ngdc.noaa.gov/mgg/geodas/trackline.html (marine gravity, bathymetry, magnetics and airborne magnetics)
- Could we make the package but still keep the individual packages. Would just have to `from fatiando_data import *`
- But the package would be a mandatory dependency in this case, which we might want to avoid.
- New `fatiando` meta-package that includes Verde, Pooch, Harmonica, Boule and Rockhound?
- Previous Fatiando users will complain that they don't get the `fatiando` Python library.
- Could help the project feel like a single project instead of individual packages.
- Another things would be to have a Fatiando wide tutorial that brings all the packages together.
- Could be done in a separate repo backed by Binder and a notebook or two.

**Notes**

- First ever community call :confetti_ball:
- The meeting will be recorded an uploaded to our Youtube channel: https://www.youtube.com/FatiandoOrg
- Introductions :wave: :
- Name
- What you do
- Location
- Favorite text editor/IDE