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.

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

AO functionality #29

Open
12 of 29 tasks
briochemc opened this issue Feb 25, 2020 · 0 comments
Open
12 of 29 tasks

AO functionality #29

briochemc opened this issue Feb 25, 2020 · 0 comments

Comments

@briochemc
Copy link
Member

briochemc commented Feb 25, 2020

A worthy successor to the AWESOME OCIM (AO) should include all the functionality of the AO.
I try to reuse the AO nomenclature for reference, and will update with AIBECS names if I change them.

Thi issue will serve me as a check/TODO list to incorporate things one can do in the AO into AIBECS:

  • backstage + data In the AO this is were the preperocessing of data occured. I would like to add functionality to provide this datasets and fields in a grid-agnostic way:
    • Nepholoid source for nepholoid layer flux. The original data comes either from eddy kinetic energy (EKE) or from some global interpolation of ~9000 particle observations. Check the references in the AO paper.
    • HEFLUX for hydrothermal flux. The AO data comes from the OCIM output, as the He source injection points and magnitudes are part of the inversion. These can now be loaded after via grd, T, He3, He4 = OCIM2.load().
      • Upload the He source fields online and write a tiny separate package so that it can be then regridded to other grids
    • WJ18 for a state-of-the-art estimate of P-cycling from Weber and John (2018). At some point it would be great to reproduce this model in AIBECS and provide it as a fully-fledged example/notebook, probably living separately from the docs if it is too big of course.
    • alkalinity from GLODAP
    • dust Contacted Tom Weber's for his dust sources, which is IIRC an optimized combination of 10ish atmospheric models. Providing for the functionality to do that on the fly would be great. (I.e., load the datasets and combine them in whatever way one wants). Will probably require a separate package. The aeolian sources used in the AO are now available and for any grid using the regrid function. See tutorials.
    • model grid. To check, but I think there is nothing new here, just the grid and some masks. Using OceanBasins.jl or a similar package should provide these masks as functions.
    • WOA. This should be sorted with WorldOceanAtlasTools.jl.
    • GEOTRACES. This should be sorted with GEOTRACES.jl. Although programmatic download of the data is still unavailable due to GEOTRACES' data committee restrictions.
    • GLODAP. An external package for using this data is probably required. Check that it does not already exist to be sure.
    • Rivers. I should add the rivers as present in the AO for Nd modelling into an extra file. But I need to make the locations and flows to be grid-agnostic before. The 200 major rivers from the Dai and Trenberth dataset are now available.
  • srcsnk. This are the functions for creating sources and sinks and transport matrices. I should check them all by one and make sure I have a functionality to match it. Some of them use prescribed data though, so if the data is loaded through a grid-agnostic function, I may need to rethink the formulation. Also the obvious translation from implicit to explicit transport might require some work. (A 👮‍♀ smiley indicates that it is used in the Cu model)
    • bioalpha.m
    • biobeta.m
    • fbiobeta.m 👮‍♀
    • bioredfield.m
    • boundcon.m (sort of natural to implement in AIBECS with a fast relaxation term)
    • conc.m (with a slow relaxation term)
    • decay.m 👮‍♀ (with a decay term)
    • dust.m 👮‍♀
    • hydrothermal.m
    • nephloid.m 👮‍♀
    • [] nonrevscavPOC.m
    • revscav.m (using a transport operator and reaction constant)
    • revscavPOC.m
    • frevscavPOC.m 👮‍♀
    • river.m 👮‍♀
    • photoout.m 👮‍♀
  • GUI. Not sure this will be implemented. Jupyter notebooks are a great (better?) alternative. They require a bit more involvement, but François thinks exposing users to a bit of code is as an advantage.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant