-
-
Notifications
You must be signed in to change notification settings - Fork 74
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
Docs housekeeping #715
Docs housekeeping #715
Conversation
Why aren't the figures being generated dynamically as an example block? |
I have an example block before. However, given that it is re-run every time the docs happen, and that there is a potential chance that the parameter fitting fails (possible especially when we make the initial example using a single run), making the doc look funny, I simply pasted in output figures from a run I made. That way there is no risk they change every time. |
But if that is the case isn't this a bad example to ask a new user to try running themselves? If they run it and it fails they will likely be quite confused and assume they've made a mistake. |
If it was an example where that happened frequently, I would agree. I just did 25 runs of the fitting and they all turned out fine, this is mostly me being paranoid. Ideally (and especially for difficult problems) one should use multistart-optimization, however, I wanted to build things up from the beginning with the simplest case, and not overload the user. If you want I could add a note of this. |
Looks like CI is passing now, but I would still strongly prefer we keep example code as I just think we get a lot of value from being able to see that a doc is suddenly not working, which we lose when things aren’t |
So, I definitely agree that the automatic testing that using Optim
using QuasiMonteCarlo
res_ms = calibrate_model_multistart(petab_problem, IPNewton(), 10, "OptimizationRuns"; sampling_method=QuasiMonteCarlo.SobolSample()) where the code actually saves the output to a file. I did not want our doc code to start saving stuff to the documentation, hence this was disabled. |
If the files are small we could have them saved into the assets folder dynamically. But I’m ok with files that are saved or loaded being premade. I’d prefer figures are dynamic though since they are easy to scan to see doc problems. |
Typically I find problems by noticing the absence of figures… |
yeah, this way it is only really showing up in the doc logs when you happen to have a look at it, so def not perfect (and there might also be problems that do not involve throwing an error as well) |
I could add a hidden line that directly deletes the generated folder |
f8ba6e2
to
6d131c1
Compare
Yes, we don't want to keep adding new folders everytime this runs within the doc hierarchy. If you can tell PETab where to create it though you can just use |
Or make sure to delete and overwrite the old sub files/folders. |
I could add a hidden line (before the line which saves the data to the folder), which create the folder (and then delete the folder later in the routine. |
Sure |
Updated (but just want to check that it all builds nicely before merging). |
This reverts commit 0724882.
40fa609
to
42298c3
Compare
f20d62a
to
f624106
Compare
Co-authored-by: Sam Isaacson <isaacsas@users.noreply.github.com>
Co-authored-by: Sam Isaacson <isaacsas@users.noreply.github.com>
Co-authored-by: Sam Isaacson <isaacsas@users.noreply.github.com>
Co-authored-by: Sam Isaacson <isaacsas@users.noreply.github.com>
→
to-->
.