The current state
Class structure
Gliffy Diagram | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
- Three classes displaying similarly looking (but not the same!) extra namelist panels:
- Grid2DExtraInputPanel
- Used by Grid2D application
- A member of Grid2DNamelistPanel that extends CenterPanel
- ENamelistPanel
- Used by Edge2D application
- A member of EGoNamelistPanel that extends CenterPanelCheck (that extends CenterPanel)
- ExtraNamelistPanel
- Used by Jetto, Sanco, Mishka, Helena, Elite
- A member of OutputExtraNamelistPanel that extends CenterPanelCheck (that extends CenterPanel)
- Grid2DExtraInputPanel
Challenges
- Complex legacy code
- The current implementation violates Model-View-Controller principia:
- No clear separation of data and GUI that makes both 'tightly coupled'
- Some data are kept in table 'model'
- GUI influences the way data are storing
- Arrays specified as a set of entries: (variable name, index, value)
- Quite a lot of time spent on 'reverse engineering' essential to understand dependencies and internal mechanisms working 'under the hood'
- How / from data are being read?
- How / where data are being saved?
- Necessity to kept backward compatibility in terms of produced output files
Development
GUI
NewExtraNamelistPanel
class, replacingExtraNamelistPanel -
designed and developed- package jet.misc.extranamelist.gui;
Progress:
- GUI development
- simplification of architecture table is resizable
Integration of NewExtraNamelistPanel
class:- Integrated:
- Jetto
- Sanco
- Mishka
- Helena
- Elite
- Not integrated (not handled by a common class - see below)integrated
- Grid2D
- Edge2D
- Integrated:
- Additional dialog to present variable data and metadata and to edit value
Data handling
- A Variable class:
- name
- overview
- obsolete
- Specification class
- namelist
- model
- tab
- Data class
- meta_type
- type
- value
- Info class
- link
- description
Open points
Config files
YAML file format
YAML file format to be finally accepted.
Code Block | ||
---|---|---|
| ||
# any comments can be put here (manually!!!) .... e.g.: ############################################### ### ITRFASTIONS. ### ############################################### - name: ITRFASTIONS overview: Short description of variable obsolete: false specification: name_list: NLIST3 model: "" tab: "" data: !<array> meta_type: array type: integer default_value: "" info: link: http://documentation.server/link/to/documentation/page description: ' Weiland model switches' |
...
- Working ('dirty') mechanism for conversion of configs prepared (can be extracted)
- Every time 'old' config file is read, the new one is saved
- Files saved to
"jams/v210321_gateway_v5/java/lib/jet/misc/extranamelist/resources/" + config_name + ".yaml"
- What should be an 'final' destination for them?
...
Settings
File format
Code Block |
---|
OutputExtraNamelist.selItems.cell[0][0] : EUP OutputExtraNamelist.selItems.cell[0][1] : 1 OutputExtraNamelist.selItems.cell[0][2] : 2.5 ... OutputExtraNamelist.selItems.columns : 3 OutputExtraNamelist.selItems.rows : 17 OutputExtraNamelist.select : true |
...
- Can
updateNamelist
method be unified somehow? Lots of IFs....
Tests
- No guarantee that ALL use cases ill be covered
- A person that could check use-cases and compare outputs
Installation
PREPARE ENVIRONMENT
...
Code Block | ||
---|---|---|
| ||
module use /pfs/work/g2fkoech/jintrac/v210321_gateway_v5/modules
module load jintrac/gateway.gfortran
cd ~/work/cmg/jams
jams-test/java/sh/jams |
...