Analysing D-Foundations and/or D-Settlement with DFoundationsAnalysis and/or DSettlementAnalysis respectively gives a TypeError (Nonetype object is not iterable) when trying to get the results files out using .get_output_file().
Expected Behavior
Since the documentation says that an .err and/or .error.log file can be obtained. I expect to be able to get those files instead of getting a TypeError. When using the same input files in the software, I can see an error log and I would like to get that error log using this automatic analysis.
I’m not sure if I understand correctly, but it seems you’re running get_output_file(). In that case the extension defaults to get_output_file(extension='.sto', *, as_file=False), meaning you are trying to access the .sto file (which doesn’t exist).
Could you run get_output_file('.error.log'), to get the error log?
I get the TypeError than aswell. For what I can see, I think that when there is an error in the analysis no files are created, so when you try to take any output file it tries to iterate over None.
You’d need to monitor the job/worker while clicking the button, but I think your hunch is correct. One thing that could happen indeed is that there is no file created at all. If a d-series analysis runs and fails you’d get an error file, but if for example d-series tries to start but there is a license error or something else preventing the program to start altogether, you could end up with a situation in which you get no resulting file at all, full stop!
The best thing to do I think would be to see the actual log/job folder on the location of the worker while you trigger it from your app, is that feasible?
The analysis do run and there is not LicenseError or anything, it gives only a TypeError when I try to take out the files, normally when a file does not exist it gives a warning that it does not exist (when the analysis goes right and you try to get the error log) and continues the code.
I would assume this is a bug, but when this is not and you got succesfully the error log from a D-Settlement analysis, let me know and I will check my code again.
It seems you have access to the server where the worker is, as you can show the logs. Can you then also see the jobs folder and check what happens when a job is triggered? Can you see the actual input file landing, and the output file being created? They are only shortlived but if you time it right you could copy it and inspect it.
These files are way too shortlived to be able to catch and copy. The input file is exactly the same, when I run it in D-Settlement myself I see the error log. But I cannot get the error file using DSettlementAnalysis().get_output_file(“.error.log”). I get a TypeError (which is not documented being possible to get), I again assume this is a bug, except if you tell me that you were able to get the error log from DSettlementAnalysis (or D-Foundations).
Hi @LuukS, was just trying to think along with you and help you figure out whats going on with this calculation, because it’s not computing, right?
In terms of there being a bug that seems to be the case, if you specify you want to get an error log back and you’re not getting it, that’s definitely not intentional. The difficulty is that without knowing if that .error.log file does actually materialize, it’s hard to say where the bug is. If the file does occur, but the worker is not sending it back, that’s obviously a bug. If the file does not occur at all, then it makes sense the worker can’t send it back, but we’d still like to figure out why it doesn’t occur. Hence my questions.
When I calculate the .sli file inside D-Settlement, it ‘calculates’ and gives me an error log with what i have to change in the input. My goal is to get that log into my application. I expected that to happen with getting the .error.log following the documentation of the get_output_file method.
Hi @LuukS, sorry for my late reply, I got sick last week and only returned today. I think I’ve reproduced your error succesfully. Weirdly, even kicking off the dsheet calculation via batch option from the terminal (which is roughly what the worker does) results in the same error and creation of log files, only I see 2 log files occurring, perhaps that’s a lead for my colleagues to look into this. In any case it’s strange that this also does not raise an actual ExecutionError. Will let you know what we find, thanks for your patience
No problem, it is not a breaking issue, but I see that there is an option to send more information to the user if a calculation in D-software fails. ExecutionError is possible maybe, but I rather have the error log to send to the user. Curious about what this will lead to
I looked into this together with my colleague @rdejonge and we found the bug. Raoul created a new version of the worker that allows reading .log files (so you can use get_output_file('.log') and that should work. You can download this new version of the worker from the Integrations page in you VIKTOR environment. Let me know if that fixes it for you!?
