You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The HECRAS engine and model folders can be very volatile. We try very hard to look for combinations were we know that the HECRAS engine will fail. We want to catch them ahead of time if possible. Why? if the HECRAS engine finds an error while processing, it does not return a fail code back to your scripts. It puts up windows dialog error boxes asking for the user to hit "Ok" or "Cancel" and doesn't always return the multi-proc, process back to the script. This can result in orphaned Windows processes and even memory leaks. Get enough of them and you can crash the machine.
Earlier, we chose to delete some files in the model folder if they were known to be bad. In hindsight, we should have tried to see if we could just rename the extension and see if HECRAS will ignore that file. ie) instead of being a .g01 file, we rename the extension to .g01z. It is unproven if this will work. However, with the current system of deleting the files, it is hard to go back and debug what happened after the fact.
If we try the trick of renaming the file extension, we can see if the theory of HECRAS ignoring those files. I have put TODO notes in he top of the create_shapes_from_hecras.py.
We should see if we can get our system to ignore folders that start with "z_". Not exactly sure where we can plug this in to see if it would help and it might also be in the create_shapes_from_hecras.py but letting the code rename the model folder will likely help as well.
The text was updated successfully, but these errors were encountered:
The HECRAS engine and model folders can be very volatile. We try very hard to look for combinations were we know that the HECRAS engine will fail. We want to catch them ahead of time if possible. Why? if the HECRAS engine finds an error while processing, it does not return a fail code back to your scripts. It puts up windows dialog error boxes asking for the user to hit "Ok" or "Cancel" and doesn't always return the multi-proc, process back to the script. This can result in orphaned Windows processes and even memory leaks. Get enough of them and you can crash the machine.
Earlier, we chose to delete some files in the model folder if they were known to be bad. In hindsight, we should have tried to see if we could just rename the extension and see if HECRAS will ignore that file. ie) instead of being a .g01 file, we rename the extension to .g01z. It is unproven if this will work. However, with the current system of deleting the files, it is hard to go back and debug what happened after the fact.
If we try the trick of renaming the file extension, we can see if the theory of HECRAS ignoring those files. I have put TODO notes in he top of the create_shapes_from_hecras.py.
We should see if we can get our system to ignore folders that start with "z_". Not exactly sure where we can plug this in to see if it would help and it might also be in the create_shapes_from_hecras.py but letting the code rename the model folder will likely help as well.
The text was updated successfully, but these errors were encountered: