Stofs 2D Support #31
Stofs 2D Support #31
Conversation
Got it, I have tested this out and it does indeed give more comparable results. |
| x_var, y_var = mesh.node_coordinates.split(" ") | ||
| x, y = ds[x_var], ds[y_var] | ||
|
|
||
| # NOTE: When the first dimension is "nele", the face_node_connectivity |
There was a problem hiding this comment.
According to the UGRID spec:
"""
The connectivity array will thus be a matrix of size nFaces x 3.
"""
so the "nele" dimension should always be first in a compliant file.
If we are finding files that. need to be transposed (ADCIRC?) -- what to do?
I think that should be handled by a pre-processor -- the make compliant function:
assign_ugrid_topology
If we are consistent about that, then we'll save a lot if blocks in the core code, like here.
There was a problem hiding this comment.
I do not think the preprocessor should mess with the dataset itself personally, but I can be convinced maybe.
Yes the ADCIRC files have reversed dimensions on the face node connectivity, which could happen with any dataset really.
There was a problem hiding this comment.
You are probably right -- as much as I want to be pedantic about the standard, we shouldn't actually change anything (as opposed to adding metadata) in the process unless the user asks for it ...
3 participants
@omkar-334 Please test out this PR.
When I download the data locally, the subset takes 4.0s, but when using the s3 version it takes a minute or minute and a half.
I am happy to chat through these changes with you so you understand. The issue here is that the dimension ordering for the face node connectivity was reversed from the ordering that FVCOM uses, so we have to make the ugrid subsetter aware of this.
I looked at the comparison with thalassa and I believe the difference in speed has to do with the reindexing and the the element selection but i am not sure. But this should give results that are more comparable I believe.
#16
#9