[Bug] - PRJ period startdates not treated by iMOD Python as in iMOD5

Open
#1,828 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
python
Domain
backend

Research direction

Start by tracing the iMOD importer’s period parsing and datetime handling, then compare its behavior with the documented iMOD5 rules for year 0000. Done means year-0000 period start dates are handled correctly and the winter2 behavior is addressed or documented as a known issue.

Written by the indexing model from the issue text.

Description

backwards_compatibility bug

Bug description
We were struggling quite a lot with how to handle the period startdates of the projectfile in python, given that the years entered are usually outside the nanosecond range. We resorted to just ignoring the year that is entered, and replacing it with 1899, which is outside iMOD5's calendar range, so doesn't result in conflicts with regular transient packages.

However, this is not how iMOD5 treats period startdates, from the manual:

Startdate of the given period. A PERIOD repeats until another time
definition is more close to the current timestep. Specify the date as
dd-mm-yyyyhh:mm:ss, so to specify midnight for the 6th of September
it needs to be entered as: 06-09-2018 00:00:00. If this need to applied
each year the notation is 06-09-0000 00:00:00 which means that it applies 
for the 6th of September no matter what year. Another example for
a repition per 6 hours is 00-00-0000 06:00:00, in this case for each day,
from 6am this packages applies.

I don't think we need to support the per 6 hour stuff, as I've never seen this in the wild. However, supporting the year 0000 needs to be done. Unfortunately, datetime.strptime() doesn't support the year 0, at minimum it requires the year 1, which is quite surprising.

I've also seen this for IBRAHYM:

Periods
winter1
01-01-0000 00:00:00
summer
01-04-0000 00:00:00
winter2
01-10-0000 00:00:00

Apparently, iMOD5 doesn't properly forward winter2, so they created this workaround.

Dominant language
Python
Stars
41
Forks
12
Avg merge
20h 23m
Merged PRs (30d)
2

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Deltares/imod-python

All issues in Deltares/imod-python

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.