You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is created to serve as a focal point for discussion/information about the 2020.04 release. My plan is to keep general information in the issue description, and then we can possibly create separate comments in in this issue for specific topics.
GitHub milestone and label
I have created a milestone "Release 2020.04" in all the GitHub repositories. You are encouraged to mark your PR's with this milestone, at least when the dates for creation of release branches draws near it is important that the PR's are marked. The way I interpret these milestones markers is as follows:
Before the release branches are created this is just a heads up to
me that: "Joe developer want's this feature in the release".
After the release branches are created I will watch the PR; if it is
merged before the final release there are two possibilities:
I decide to backport the feature to the release branch - in that
case the "Backported 2020.04" label is added to the PR.
I decide to not backport the feature to the release branch - in
that case the PR will be removed from the "Release 2020.04"
milestone.
Important dates
Creation of release branches: Wednesday 22.th of April
Creation of release candidate 1. Friday 24.th of April
Release canditate2 / final Friday 1.st of May
(Absolute final release date: Friday 8.th of May)
The text was updated successfully, but these errors were encountered:
Eclipse does not consider the historical part of the Schedule section when restarting, all necessary well and group information is collected from the restart file, and the interpretation of the SCHEDULE keywords starts right at the restart date. For opm/flow the restart semantics has traditionally been different:
The Schedule file is parsed in it's entirety - and that information is used to initialize wells and groups and such.
Only the solution fields like PRESSURE and SWAT is fetched from the restart file.
With the ongoing (very close to "complete") work: #1396 flow is also capable of restarting without access to the restart file - for flow this is regulated with a command line switch. To restart based on the full schedule file (original opm behaviour):
flow --sched-restart=true CASE.DATA
and the new capability of restarting based only on the restart file is invoked with:
flow --sched-restart=false CASE.DATA
Currently the --sched-restart=true is the default behavior; we should be going in a direction where this is changed to --sched-restart=false is the default behavior - but my question is whether we should change the default for the release or not? To evaluate this question it is important to keep in mind that the new --sched-restart=false is complex, and only tested on a limited set of models - I therefor consider it quite probable that models which have worked with the original opm restart scheme (i.e. --sched-restart=true) will fail to restart with the new --sched-restart=false.
My preference is:
For the release we retain the --sched-restart=true behavior.
Soon after the release we switch the default to --sched-restart=false - hopefully this will weed out enough problems among developers that it is a safe setting for the next release.
This issue is created to serve as a focal point for discussion/information about the 2020.04 release. My plan is to keep general information in the issue description, and then we can possibly create separate comments in in this issue for specific topics.
GitHub milestone and label
I have created a milestone "Release 2020.04" in all the GitHub repositories. You are encouraged to mark your PR's with this milestone, at least when the dates for creation of release branches draws near it is important that the PR's are marked. The way I interpret these milestones markers is as follows:
me that: "Joe developer want's this feature in the release".
merged before the final release there are two possibilities:
case the "Backported 2020.04" label is added to the PR.
that case the PR will be removed from the "Release 2020.04"
milestone.
Important dates
The text was updated successfully, but these errors were encountered: