LIVVkit issueshttps://code.ornl.gov/groups/LIVVkit/-/issues2019-05-02T18:54:02Zhttps://code.ornl.gov/LIVVkit/lex/-/issues/4Turn LEX analyses into a class2019-05-02T18:54:02ZKennedy, Joseph Hkennedyjh@ornl.govTurn LEX analyses into a classThis would allow us to define some default functions(methods) that users could choose to over-ride.
For example, we could have a default `parse_config` function that looks like:
```python
def parse_config(config: dict) -> argparse.Na...This would allow us to define some default functions(methods) that users could choose to over-ride.
For example, we could have a default `parse_config` function that looks like:
```python
def parse_config(config: dict) -> argparse.Namespace:
"""Generate an arguments Namespace from the analysis config file"""
test_args = test_args = OrderedDict([(k.replace('-', '_'), v) for k, v in config.items()])
test_args = argparse.Namespace(**test_args)
return test_args
```
Which spoofs the user defining a `parse_args` function and parsing command-line options with argparse.https://code.ornl.gov/LIVVkit/lex/-/issues/3Handle extension dependencies2019-02-12T16:39:12ZKennedy, Joseph Hkennedyjh@ornl.govHandle extension dependenciesBecause each extension is likely to introduce new dependencies, there needs to be a uniform method to handle the dependencies.
**Importantly, it's not feasible to create a LEX conda package because of the size of the data, unless, the ...Because each extension is likely to introduce new dependencies, there needs to be a uniform method to handle the dependencies.
**Importantly, it's not feasible to create a LEX conda package because of the size of the data, unless, the code and data were handled independently.**
Options include:
## Conda meta-package
By creating a conda meta-package all the dependencies could be handled via conda and this repo can be installed independently.
## Simply list in a `conda.yml` file
This is simpler than creating a meta-package, but requires people to manage their environments directly -- something that doesn't work well for ESMs as their analysis environments are usually set up by a sys. admin, and would be hard to include LEX dependencies.
## Adopt a data-only storage idea for this repository
Move the analysis code into LIVVkit proper, leaving only the data files behind. This will, however, make LIVVkit a much bigger package than needed for EVV and simple verification use.Kennedy, Joseph Hkennedyjh@ornl.govKennedy, Joseph Hkennedyjh@ornl.govhttps://code.ornl.gov/LIVVkit/lex/-/issues/2E3SM analyses should use ice sheet area2018-11-17T01:07:33ZKennedy, Joseph Hkennedyjh@ornl.govE3SM analyses should use ice sheet areaCurrently the E3SM analyses use the land gridcell area to weight the calculations, but really should be using the fractional ice-sheet area. This fractional area is usually contained in the `gris_area` or `aais_area`, but in the current ...Currently the E3SM analyses use the land gridcell area to weight the calculations, but really should be using the fractional ice-sheet area. This fractional area is usually contained in the `gris_area` or `aais_area`, but in the current E3SM compsets, these are all zeroed out.v0.2.0Kennedy, Joseph Hkennedyjh@ornl.govKennedy, Joseph Hkennedyjh@ornl.gov