Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DEFECT] ensemble model indexMap is destructive process #1119

Closed
10 tasks done
PaulTalbot-INL opened this issue Dec 13, 2019 · 4 comments · Fixed by #1450
Closed
10 tasks done

[DEFECT] ensemble model indexMap is destructive process #1119

PaulTalbot-INL opened this issue Dec 13, 2019 · 4 comments · Fixed by #1450
Assignees
Labels
defect priority_normal RAVENv2.1 All tasks and defects that will go in RAVEN v2.1

Comments

@PaulTalbot-INL
Copy link
Collaborator

PaulTalbot-INL commented Dec 13, 2019


Defect Description

Describe the defect

What did you expect to see happen?

When using an EnsembleModel and ND data with multiple output DataSets, the order of the output data sets shouldn't matter.

What did you see instead?

The output works as expected for the first DataSet; the second does not receive the _indexMap metavariable.

Do you have a suggested fix for the development team?

Check for destructive dictionary actions in the index map creation, perhaps, during output collection

Describe how to Reproduce
Steps to reproduce the behavior:

  1. Write a MultiRun using a model producing ND data that is stored in two different output DataSets
  2. Run it

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

  • 1. Is it tagged with a type: defect or task?
  • 2. Is it tagged with a priority: critical, normal or minor?
  • 3. If it will impact requirements or requirements tests, is it tagged with requirements?
  • 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
  • 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)

For Change Control Board: Issue Closure

This review should occur when the issue is imminently going to be closed.

  • 1. If the issue is a defect, is the defect fixed?
  • 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
  • 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
  • 4. If the issue is a defect, does it impact the latest release branch? If yes, is there any issue tagged with release (create if needed)?
  • 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?
@dylanjm
Copy link
Collaborator

dylanjm commented Nov 10, 2020

Found this same bug trying to output dispatch results for HERON.

@PaulTalbot-INL
Copy link
Collaborator Author

Hit this again; due to the fact output collection is buried in a lambda function, it's challenging to trace. No realistic user could possibly guess the right order of outputs to prevent this from happening.

PaulTalbot-INL added a commit to PaulTalbot-INL/raven that referenced this issue Feb 25, 2021
@PaulTalbot-INL PaulTalbot-INL self-assigned this Feb 25, 2021
@alfoa
Copy link
Collaborator

alfoa commented Feb 25, 2021

Closure checklist passed...

Closure approved via #1450

@alfoa alfoa added the RAVENv2.1 All tasks and defects that will go in RAVEN v2.1 label Feb 25, 2021
@alfoa
Copy link
Collaborator

alfoa commented Feb 25, 2021

No email is required since this issue could just cause a crash and not wrong results.

alfoa pushed a commit that referenced this issue Mar 8, 2021
* maybe fix for ens model and index map

* Closes #1119

* reducing test size

* adding gold dir to path

* reordered dataobjects to appease overly strict xsd

* undoing test from another branch
joshua-cogliati-inl pushed a commit that referenced this issue Mar 11, 2021
* Closes #1119

* reducing test size

* adding gold dir to path

* reordered dataobjects to appease overly strict xsd

* undoing test from another branch

* netCDF r/w tests, implementation; not in multirun yet

* netcdf differ, netcdf in multirun

* xsd, when testing just is not strict enough and more failures are needed

* RrR with database return

* doc update

* added nd handling error to HDF5

* writing twice to netcdf works as expected

* fixed sample ID alignment for multiple netcdf writes

* variablegroups in databases and other input params

* clarify comments, remove debugs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
defect priority_normal RAVENv2.1 All tasks and defects that will go in RAVEN v2.1
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants