RossWrapup

These are some of the major difficulties/deficiencies/oversights that exist in TsuDAT today as I see it:

Need to modify UI so it can't manoeuvre ANUGA into a failure.

There are 'loop holes' in the UI that allow the user to run a job that must fail. Some examples:

• The user can ask to extract on the AoI, but may not have defined an AoI
• The user can specify a mesh resolution/friction polygon with a zero value
• The user can define illegal polygons

The usual way of removing these difficulties is to build more 'smarts' into the UI to, for instance, grey out the “extract AoI” choice if no AoI is defined, better defaults for polygon values, more checks on user-entered values, etc.

If the user enters an AoI (say) that overlaps with the sim area the user should be told at the time s/he defines the offending polygon. This means code in the UI that duplicates the ANUGA functionality, but so be it. True, difficult questions arise, like “do we do this in ecmascript in the browser or python on the server?”.

Similarly, TsuDAT is modifying the sim area so it's slightly different from the sim area the user entered. We must make this apparent to the user. Presumably, just after s/he defines the sim area we must redraw it in the view. This make it much more unlikely that the user will draw an illegal interior polygon.

More feedback to user about what to do next.

I was asked many times “why can't I go to the next step?”. Usually the user had forgotten to enter a scenario name or something similar. I'm not sure what is technically possible here, but there is code that runs on every change in the UI and enables or disables the “next step” bar. This code could, for instance, put a tooltip on the next step bar showing one reason why the bar is not enabled. For instance: “You must enter a scenario name”. After all, something is deciding to enable the bar or not, so that code must know what the reason for not allowing progress to the next step is.

Jobs that STOP but never get DONE?

There are instances of jobs (job 534) that get to a STOP status (ie, have sent a STOP message) but never progress to a DONE status. I've not been involved with the code at that level, but that seems to be a bug? Can the user see any results?

Possible to enhance ABORT messages with a one-line explanation that user can see?

The ideal is for ANUGA not to ABORT, but if that does occur the user sees nothing beyond the ABORT status. It is possible for the code running on the instance to extract a one line description from the stacktrace and send that in the ABORT message in addition to the stacktrace itself. This one line explanation could be shown to the user, whereas the stacktrace would not be helpful.

The one line explanation could initially just be the ANUGA message. The ANUGA messages should be changed to be a little more 'user friendly'. See below.

Sign-in screen should place focus in the Username field.

When signing in the user is presented with a form with no focus in any field. I'm sure it's just a oversight, but the focus should be placed into the Username field.

Some links questionable.

This is surely just an oversight in the rush to the workshop usage, but clicking on the “Help” link at the bottom of the “About TsuDAT simulator” dialog gets a GeoNode help page. I expected something more TsuDAT-specific.

Spelling errors.

I haven't done a full check, but one spelling/grammar error is in the disclaimer text: “In on event” should be “In no event”.

Though this must be considered future, blue sky, stuff, here are some comments on ANUGA itself:

ANUGA shouldn't be limited by “one UTM only” in ANUGA.

There is code in ANUGA to check that various points/polygons lie wholly within one UTM zone. My feeling, reinforced by a (misremembered?) conversation with Ole Nielsen a long time ago, is that there is no technical necessity for this. Please check with Ole.

True, large simulation areas have errors since ANUGA models in a flat 2D workspace, whereas the world is round. But UTM zones are entirely artificial. If a sim area polygon in, say, Victor Harbour lies on the boundary between two zones but the polygon is smaller than the extent of one zone, why not treat eastings/northings as lying in one large (double) zone. Or define a convenient origin anywhere to the west of the polygon from which to calculate eastings/northings. I don't think ANUGA cares.

We could issue warnings along the lines of “polygon spans multiple UTM zones, continuing...”.

ANUGA abort messages need a cleanup.

This is related to the “enhance abort messages” point for the UI above, but is repeated here for completeness.

The text of messages that ANUGA issues on an exception should be reviewed now that non-ANUGA adept people are using ANUGA. They should make more sense in the TsuDAT environment.

ANUGA logging cleanup.

Related to the point above. ANUGA logging should be cleaned up. There are still raw prints in ANUGA and these should be deleted or the message logged, not printed. The log levels should also be revisited. Most logging occurs at the CRITICAL level, and that's not useful.

One problem running ANUGA 'embedded' with TsuDAT code on an instance is that the ANUGA logger doesn't play well with the TsuDAT handling of logging. The current workaround is to turn off parts of the ANUGA log system. Logging should be rethought so it's useful in both the traditional standalone mode as well as running under TsuDAT.

The TsuDAT ABORT point above could also be solved here. ANUGA could log a TsuDAT-specific message in some easily extracted form and TsuDAT could send that back to the UI?

I guess the point here is that ANUGA should be rethought so it fits in with controlling harnesses like TsuDAT a little better. It was originally written as a library to be used by a knowledgeable user, and it shows!