[FEAT-UI]: Create Hydrograph screens wireframe (h5 & inputs)

[martyheynbah]

• Create wireframe for the page where user uploads and views H5 files

• each h5 has a savepoint that is relevant within the project

• each savepoint needs 2 h5 files (1 for water level and 1 for waves)

• Create wireframe inputs page

[martyheynbah]

@trietmnj ready to review initial wireframes at https://www.figma.com/design/1QbZXT6sEOStX7yHmX9ilK/CHART-tmnj?node-id=415-339&p=f&m=draw

For this screen there will be an upload button for each type of H5 file (water level and waves). The button will be disabled based on:

• if a Savepoint is selected to add files too
• if there us already a tidal or assert h5 file in the db or s3 for the savepoint

@trietmnj also curious what type of data should go in the table for h5 files? Not sure what metadata we can pull in via s3 or the db?

[martyheynbah]

This page is just simple inputs:

Would love any ideas on how to spruce this up (and if all input criteria is met)

[trietmnj]

1. On the first screen - not sure if uploading individual water level + wave files with the two buttons lends itself to the workflow. Maybe a study of 10 reaches -> 20 times they have to go through the same process, not to mention the modifications they might have to go through on model validation.

Would a multi-file upload work here at first? Only after the upload, you can have the mechanism to the relationship between the reach and the files? Then we also need to think about the workflow on when there is already data. They would need to delete an established relationship or replace the file. The mental map is something like 1) you have the reaches, 2) each reach creates 2 placeholders for H5 files - this already creates the relationship, 3) upload a pool of H5 files - on revisits the modeler can add or remove items from this pool, then 4) map the placeholders to the files in the file pool.

In terms of the columns on the table maybe: reach, savepoint, data type (either water level or reach), and then file name.

2. On the second screen - the SLC can get a little tricky. Previously, we did discussed how a study can have multiple modeling runs, and it is very common to assess how damages vary across the different SLCs. So it might do good to think about the overarching workflow here. Let's say each "Run Process" on this screen generates a different set of manipulated hydrographs. Each would need to be identify in a way that it is distinct from the other sets. So maybe we should add in the Name and Description fields? And then when we get to the Eurotop, the user can select which set of hydrographs to use.

EDIT: this is when the modeling takes a branching path. Whereas so far the workflow so far is sequential, the SLC introduces a branching path. The data flow is something like this diagram

[martyheynbah]

Alright, I know we talked about formatting this similar to the Erosion modal, but I thought of another approach I wanted to share before moving onto that one:

1. Users upload all files at once into the file pool which is saved in client state
2. Because it seems that the H5 file names contain a Savepoint_ID the system will automatically map files to savepoints based on predefined conventions (ID and File Type) and fill in the table column
3. The table will also allow for manual assignment via a dropdown or edit button within the table column
4. Users can review mappings, replace files, or delete them as needed.

[martyheynbah]

Also for the second screen I added "Name" and "Description" fields to allow each modeling run to be uniquely identified and described for better tracking.

[trietmnj]

Updated dataflow diagram

[trietmnj]

Alright, I know we talked about formatting this similar to the Erosion modal, but I thought of another approach I wanted to share before moving onto that one:

1. Users upload all files at once into the file pool which is saved in client state 2. Because it seems that the H5 file names contain a Savepoint_ID the system will automatically map files to savepoints based on predefined conventions (ID and File Type) and fill in the table column

I know we talked about the filenames, but idk how consistent those SP ids will be and there is no guarantee those file naming will be the same as the convention. I have seen use-cases where the modeler would add in a correction by modifying the original data, and then saving a completely new file.

We could try, but I don't think we can make the assumption that the file name will follow CHS convention. Punting the relationship mapping responsibility to the modeler should at the very least be mandatory either way.

4. The table will also allow for manual assignment via a dropdown or edit button within the table column
5. Users can review mappings, replace files, or delete them as needed.

For the second screenshot, I think Fabian mentioned alpha is something inherited from the NOAA API.

And then also thinking about the simulation start and end date with the data flow. Working on the data flow diagram just now, I remembered specifying the simulation start year and duration for lifecycle generation, I think we can derive from that config. Ingesting another set would create a secondary source of truth, which we don't want.

[martyheynbah]

I know we talked about the filenames, but idk how consistent those SP ids will be and there is no guarantee those file naming will be the same as the convention. I have seen use-cases where the modeler would add in a correction by modifying the original data, and then saving a completely new file.

We could try, but I don't think we can make the assumption that the file name will follow CHS convention. Punting the relationship mapping responsibility to the modeler should at the very least be mandatory either way.

Awwww bummer, this approach assumed that the savepoint data we are using would match the savepoint_id used in the filename. Do you have any test files I can look at to confirm or deny if this will be possible?

If not the user would still be able to add files to each reach/savepoint in the table via a dropdown in the file column