oemof-solph
oemof-solph copied to clipboard
Error handling oemof app development (collect errors that are badly handled)
Hey,
I frequently realize, that when developing application I create errors by wrong instantiation and these are often not very helpful. I can handle most of them, because I know the source code and solph very well.
What I would like is to collect mysterious error message and the cause for it, so that we can improve error handling for users.
What do you think? Where would be a good place?
That is a really good idea. We all should do that.
What about the wiki?
At the next developer meeting we could have a look at them and discuss how we can catch some of them with not too much effort.
The Wiki could be fine...However i am thinking about a process about how to keep that constantly in mind of users/developers....
This should be a top on the dev-meeting!
Should a hint on how to contribute to FAQ be added to the doc?
@p-snft do we have a FAQ already? I am not aware of any. Where do I find it? And yes, a hint on how to find it should appear in the doc.
@simnh's last comment indicates that there was none. So, I created https://github.com/oemof/oemof/wiki/Frequently-occurring-errors. Still, the wiki does not allow externals to contribute, so there needs to be something additional.
Thanks @p-snft for initializing a FOE section - many desperate users will appreaciate your approach! :) Now it is time to fill the FOE with information, so let's find some errors and describe them.
Some ToDos that I see here:
-
[ ] Mention FOE-Wiki-Page in oemof-docu (readthedocs)
-
[ ] Find a solution for:
the wiki does not allow externals to contribute, so there needs to be something additional
-
[ ] Describe some errors in the FOE to make it attraktive for users. Here we might want to define a template for error (and solution) description.
-
[ ] Make oemof's FOE famous, mention it in forums where users seek help.
Regarding the second ToDo
the wiki does not allow externals to contribute, so there needs to be something additional.
... I remember we had a session "Easy participation and oemof-support" at the Meeting November 2018 where we discussed how users/beginners that are not familiar with github could report bugs, problems, and typos they find. Back then someone (@gnn wasn't it you?) came up with the following solution:
make a form on oemof webpage which automatically creates an issue on github (how: form sends an email to a bot or a post request is send to the github API), the link to the form should be clearly visible on every page
I thought that was implemented already but now I don't find it on the webpage. If such a form exists, we could use it for error-reports too.
Does anyone know if that form was ever implemented?
I found it is possible to uncheck "Restrict editing to users in teams with push access only" in the settings of the repository's wiki. This way would allow externals to contribute to the wiki.
I added an error massage and the corresponding solution to the (FOE).... but I am not very happy with it. I wanted to provide the solution right away and ended up with a detailed and problem specific text that is not generic. Please, have a look at (FOE). I would appreaciate a feedback and some ideas how to handle this. I consider it a good case to discuss the documentation of errors :)
In my opinion the error message should be the section and then we can add a list with possible reasons:
ERROR-Optimization failed with status warning and terminal condition infeasible
The energy system (oemof.solph) is designed in a way that there is no possible solution.
-
The demand can not be fulfilled.
- Add an unlimited Source object with very high
variable_cost
that is used only when nothing else is left.... Source should be zero in the feasible case....
- Add an unlimited Source object with very high
-
No available sink for a fixed Source object
- Add an unlimited Sink object.... bla blubb
3.....
In general it looks like this.
Error message
General explaination, "What does the message mean originally."
-
First reason
- One solution...
- Another solution
-
Second reason
- Solution
3....
I like the structure @uvchik proposed and suggest to apply it!
@p-snft what do you think? I saw that you changed/removed what I wrote in the FOE but you did not leave a comment, so I can merely reckon your opinion on that ;) Do you agree on applying the proposed structure?
Sorry, @jakob-wo. I used the Wiki web interface and that does not allow to leave verbose comments. IMHO, I just shortened the content but did not really change its meaning.
As it's bullet points, the comments should be rather short. Another option would be to use headlines an be more verbose.
I leave this conversation because my research project ends this month.
Interest seems to be lost.