Comments (5)
@callistosp Thanks for the feedback.
@kyleam totally agree on bbi-1 as a solution. If this is done, I think bbi-2 would not be necessary.
Yes, I agree it'd not be necessary.
The appeal I see in it is that this info is captured in bbi_config.json
rather than left to custom logic in bbr to determine. bbi already has to determine what nm version to use, so it could record that rather than make bbr try to figure it out. But, as you say, with bbi-1 in place it really doesn't matter, so perhaps not worth the effort and config change at this point.
For bbr-2 this internal function shouldn't encounter a json with multiple defaults if bbi-1 is implemented correctly (actually, I think bbr-1 also shouldn't be an issue if bbi-1 is implemented).
Yes, that's right. bbi-1 is the only strictly necessary one. The main reason I like the idea of bbr-2 is because it's possible that a newer bbr with such a change will encounter a bbi_config.json
on disk that was generated with an older bbi (even in cases where the latest bbi is currently installed). Those may be very rare, and it doesn't matter too much because it's just replacing one error with a more appropriate one, but I think it could be worth doing given that it's easy.
from bbr.
[ Capturing some details from offline discussion ]
The root cause was the bbi.yaml
having more than one NONMEM version marked as the default, leading
resolve_nonmem_version extracting multiple versions.
So, the error is right that there is something invalid going on here that we should be catching.
Some possible adjustments (all aimed at getting a better error)
On bbr's end:
-
When
submit_model()
is called, we could catch the issue and abort. (That probably involves bbi.yaml parsing that we're not currently doing though.) -
Adjust
resolve_nonmem_version()
to abort if more than one default is found.
On bbi's end:
-
it should abort if more than one default is found
-
it'd be good for it to record the default version that it actually discovered and used in
bbi_config.json
.
My initial thinking is that we should do bbr
item 2 and bbi
item 1, with a maybe for bbi
item 2, but I'd like to hear what @callistosp, @seth127, and others think.
from bbr.
@kyleam totally agree on bbi-1 as a solution. If this is done, I think bbi-2 would not be necessary.
For bbr-2 this internal function shouldn't encounter a json with multiple defaults if bbi-1 is implemented correctly (actually, I think bbr-1 also shouldn't be an issue if bbi-1 is implemented). I might be missing an edge case though that you have in mind.
from bbr.
ahh good point about potentially different versions of bbr/bbi, that makes sense why you would want to implement in both.
from bbr.
Thanks for this discussion @callistosp and @kyleam. My take on it is that all four of those things sound potentially worth doing. I would prioritize them like:
- bbi-1
- This seems obviously necessary. We can't ever run with two versions of NONMEM, so it has to pick one. Much better to alert the user and make them pick one, than to have
bbi
mysteriously and silently pick underneath. - Related: maybe I missed it, but did we test what actually happens in this case currently? My understanding was that these models (that started this issue) were never actually run with this "2 versions" configuration, but that it was an artifact of someone modifying the json after the fact. Am I wrong about that?
- This seems obviously necessary. We can't ever run with two versions of NONMEM, so it has to pick one. Much better to alert the user and make them pick one, than to have
- bbr-2
- Maybe this is the intention, but as part of this, I think the desired behavior would be that
config_log()
itself doesn't error, but returnsNA
or something for thenm_version
column on the offending models, but that we raise a warning or something to let the user know. - I'm open to discussion on that, but I am generally not in favor of the log functions actually erroring out and not returning, unless there's a really good reason to.
- Maybe this is the intention, but as part of this, I think the desired behavior would be that
- bbi-2
- You both note that this may not be necessary, if we do bbi-1, which is true. However...
- Kyle's point here seems like a good one: "bbi already has to determine what nm version to use, so it could record that rather than make bbr try to figure it out"
- It just seems obvious to me that
bbi
should capture and record the version of NONMEM that was actually used to run the model, instead of just passing through a config that needs to be re-parsed downstream to figure it out. I think this should be unambiguous in thebbi_config.json
. Thoughts on that?
- bbr-1
- I like the idea here, but I think it's lowest priority because it mostly becomes unnecessary once we do bbi-1
- As noted though, it may still be worth doing because of differing versions floating around.
from bbr.
Related Issues (20)
- Bootstrap: function adjustments needed HOT 4
- Address deprecated warning in function `check_grd`
- Bootstrap runs should inherit attached bbi_args HOT 1
- inherit_param_estimates: revisit rounding and use matrix-handling PR HOT 1
- check_nonmem_finished and get_model_status refactor: improve wait times & change functionality HOT 9
- WK files created by bbr - delete by default? HOT 7
- Consider fail-safe for checking on terminated models HOT 4
- bbi package installation failed HOT 8
- Option to start bootstrap runs at final estimates from parent run HOT 3
- No error or warning when trying to overwrite run when `.wait = FALSE` HOT 15
- Re-name msf file in bootstrap run control stream HOT 1
- Submitting bootstrap run in batches can leave lots of unused compute HOT 2
- Bootstrap batch submission sometimes chokes when called before setup is done HOT 2
- Revisit `check_up_to_date` for `nmboot` models HOT 1
- push back minimum snapshot? HOT 5
- Feature: update $TABLE with a certain format HOT 1
- `bbi_init`: parse `nmfe_options` separately from other `.bbi_args`
- .exclude argument in run_log()
- Can't execute bbr commands via the clusters HOT 8
- Check if model can be passed to `nm_join()`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bbr.