Projectfiles can contain boundary conditions with both a "STEADY-STATE" timestamp as well as timestamps indicating actual transient or periodic boundary conditions. The data under the "steady-state" label is used by iMOD5 when building a steady-state simulation, or a transient simulation where the first stress period needs to be computed as steady-state.
Right now a keyerror is thrown in this case on the key "time", as the entry with timestamp "STEADY-STATE" doesn't have a "time" entry in the header because the "steady-state" timestamp is special-cased (I think).
We should fix the open_project_file function first. When this is done, we can assess whether we follow the iMOD5 path, or let the user select manually whether to use steady-state or transient timestamps. I think there is a reason for why iMOD5 has this functionality, as it is quite nice to have some special "steady-state" boundary conditions to drive the first steady-state stress periods.
Projectfiles can contain boundary conditions with both a "STEADY-STATE" timestamp as well as timestamps indicating actual transient or periodic boundary conditions. The data under the "steady-state" label is used by iMOD5 when building a steady-state simulation, or a transient simulation where the first stress period needs to be computed as steady-state.
Right now a keyerror is thrown in this case on the key "time", as the entry with timestamp "STEADY-STATE" doesn't have a "time" entry in the header because the "steady-state" timestamp is special-cased (I think).
We should fix the open_project_file function first. When this is done, we can assess whether we follow the iMOD5 path, or let the user select manually whether to use steady-state or transient timestamps. I think there is a reason for why iMOD5 has this functionality, as it is quite nice to have some special "steady-state" boundary conditions to drive the first steady-state stress periods.