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

Discrepancy in treatment of observation variable irefsp #586

Closed
jbellino-usgs opened this issue Jun 3, 2019 · 5 comments
Closed

Discrepancy in treatment of observation variable irefsp #586

jbellino-usgs opened this issue Jun 3, 2019 · 5 comments

Comments

@jbellino-usgs
Copy link
Contributor

Hey guys, sorry to have missed the deadline for the recent release of flopy, but I wanted to point out that the variable irefsp is treated as a zero-indexed variable when writing to file in the ModflowHob package (though not explicitly so-stated in the docstrings) and as a one-indexed variable in the ModflowFlwob package. I'd be more than happy to submit a pull request, but wanted to verify that this was not intended behavior. I'd also clarify this in the docstring to explicitly state whether to the user should supply a zero-indexed value or one-indexed value, depending on which is preferred.

line += '{:10d} '.format(t['irefsp'] + 1)

line = '{}{:10d}{:10.4g} {:10.4g}\n'.format(self.obsnam[c],
self.irefsp[c],
self.toffset[c],
self.flwobs[c])

@jdhughes-usgs
Copy link
Contributor

I think we want zero-based for ModflowFlwob. Feel free to submit a pull request. Also ideally it would be nice to have something like the Head observation object like we have for ModflowHob. Feel free to think about how to implement a flow observation object.

@jbellino-usgs
Copy link
Contributor Author

That sounds good Joe, I'll probably make a submission to address the zero-based index thing and then think about the Head observation object idea when I get some time. Also, is there any appetite for a load method for ModflowFlwob? I wrote one up based on the method for ModflowHob and have been using it for the Floridan model.

@jdhughes-usgs
Copy link
Contributor

I think we would also want a load method.

@jbellino-usgs
Copy link
Contributor Author

jbellino-usgs commented Jun 24, 2019

The idea of a FlowObservation object was interesting to me so I wrote some code to test out what it would look like. Basically the new observation object would consist of a cell group, with one or more cells, and the associated timeseries data. All of the tricky variables (nqotfb, nqobfb, etc.) would be computed by the new ModflowFlwob object upon instantiation. Let me know how you'd like to proceed and I'll share the code so you guys can have a look and see if it makes sense to do it that way.

@jbellino-usgs
Copy link
Contributor Author

jbellino-usgs commented Jun 24, 2019

As a matter of fact, here's a link to the main commit in my repo that implements the changes. Note that these changes were made prior to the commits we merged today that finalized the load functionality so the actual code will have to be updated to reflect those changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants