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

use BUMP for basic hz correlation #36

Closed
travissluka opened this issue Dec 8, 2020 · 4 comments · Fixed by #48
Closed

use BUMP for basic hz correlation #36

travissluka opened this issue Dec 8, 2020 · 4 comments · Fixed by #48
Assignees

Comments

@travissluka
Copy link
Member

travissluka commented Dec 8, 2020

implement the staticbinit.x application. This will use BUMP to calculate the files needed for a basic horizontal correlation. operator

  • enable a ctest for staticbinit
    • instead of umdsstCovar as the listed covariance in the yaml file, use BUMP
    • specify a constant horizontal correlation length (let's say, 300km ?)
  • change the dirac ctest to instead uses the BUMP static B generated from the above mentioned staticbinit ( change covariance model: BUMP)

at this point, the above dirac ctest should produce output fields with increments that are spread out horizontally

@travissluka
Copy link
Member Author

... things that I know will need to be added to the code

  • in dirac.cc and staticBInit.cc add saber::instantiateCovarFactory<umdsst::Traits>(); and the required .h file to use that function
  • add saber to the list of LIBS for those executables in src/mains/CMakeLists.txt
  • If you then try to compile you'll see that several interfaces are missing from the code:
    • add atlas::FieldSet * atlasFieldSet() const; to Geometry
    • add to following to Fields
      void setAtlas(atlas::FieldSet *) const {}
      void toAtlas(atlas::FieldSet *) const {}
      void fromAtlas(atlas::FieldSet *) {}
      

@loganchen39
Copy link
Collaborator

@travissluka When I run test for staticbinit.x, it gives the following error.
9: Create BUMP
9: Exception: FieldSet: cannot find field "sea_surface_temperature"

I am not so sure about this staticbinit.x and the background error covariance. Below are my questions.

  1. Does the staticbinit.x read an SST background, i.e. Data/19850101_regridded_sst.nc ? I've provided it in the yaml file in "background" sector. It seems not.
  2. What is the expected output from staticbinit.x? Is it a static Background Error Covariance Matrix in netCDF format? Our analysis grid is 360x180 (=64800), so will the covariance matrix be 64800x64800? I'm checking several materials, still not sure how it's implemented. I'll also discuss with Jim and go check his SODA code about this covariance matrix.

I've updated the code to feature/staticbinit.x branch.

@travissluka
Copy link
Member Author

try this in your staticbinit.yaml

background error:
  covariance model: BUMP
  bump:
    verbosity: main
    datadir: Data
    forced_radii: 1
    method: cor
    new_nicas: 1
    ntry: 3
    prefix: Chen
    resol: 6.0
    mpicom: 2
    rh: 
      sea_surface_temperature: [3000.0e3]
    rv:
      sea_surface_temperature: [1]
    strategy: specific_univariate

a couple of notes there:

  • bump works by calculating the parameters needed for the covariance matrix on a reduced grid, the size of which is determined by the correlation lengths. The output is indeed a series of netcdf files
    • _cmat.nc , the correlation lengths (i think as a fraction of earth's radius for rh) on the 360x180 grid, so filled with (3000e3/6378e3) in our case
    • _nicas_.nc files, which are the weights needed for performing the convolution, these are on the reduced grid, so not a 64800x64800 grid. One file per PE is generated, so if you ever want to run with a different number of PEs you'll have to delete the files and rerun the staticbinit program
  • BUMP gets grumpy sometimes if you change the parameters and rerun staticbinit without deleting the files first.
  • since the reduced grid size is determined by the correlation lengths, larger lengths run faster. for ctests use a big number (3000e3 here) to make it run faster. We'll use realistic lengths later.

You'll have to implement those stubs you added in Fields and Geometry, as that is where BUMP is pulling its information from.

In order to quickly get the code to run without crashing, I added:

    atlas::FieldSet * Geometry::atlasFieldSet() const {
      atlas::FieldSet * fs = new atlas::FieldSet();
      fs->add(atlasFunctionSpace_->lonlat());
      return fs;
    }

and

    void Field:s:setAtlas(atlas::FieldSet *f) const {
      f->add((*atlasFieldSet_)[0]);
    }

clearly not the correct way to it (dangling pointer!).

@travissluka
Copy link
Member Author

also, correct, I don't think the background file is read in and used for anything here

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

Successfully merging a pull request may close this issue.

2 participants