Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BoundaryData class doesn't read points file properly #37

Open
rthedin opened this issue Jul 26, 2021 · 2 comments
Open

BoundaryData class doesn't read points file properly #37

rthedin opened this issue Jul 26, 2021 · 2 comments

Comments

@rthedin
Copy link
Collaborator

rthedin commented Jul 26, 2021

When reading boundary data, the points file isn't always read correctly and thus it stops at an assertion. The function that reads the points file has this comment:

"""Detects y and z (1-D arrays) from a list of points on a
structured grid. Makes no assumptions about the point
ordering

but it does make assumptions on the ordering. In this function, the user can specify the number of points in the two directions and the code assumes certain order by doing
y = ylist.reshape((NY,NZ))[:,0]

If the user doesn't pass the number of points-- or rather, the points are in fact scrambled and the reshape above is not desirable-- it assumes one of the dimensions is varying faster in an ordered manner:

elif zlist[1]==zlist[0]:
# y changes faster, F-ordering
NY = np.nonzero(zlist > zlist[0])[0][0]

or,

elif ylist[1]==ylist[0]:
# z changes faster, C-ordering
NZ = np.nonzero(ylist > ylist[0])[0][0]

The issue is that it assumes that the slow-varying dimension is ordered. The number of points in the slow-varying dimension, obtained with, for example, NY = np.nonzero(zlist > zlist[0])[0][0] only gives the correct number of points in that dimension when zlist is equal to np.sort(zlist). The re-ordering index obtained by reading points need to be carried forward and used when reading the actual files U, T,`k', etc.

@ewquon
Copy link
Collaborator

ewquon commented Jul 20, 2024

@rthedin, I'm guessing this issue has never been fixed — did you ever come up with a fix/workaround? Desiree has been using some of this code, I think, so this may be relevant again.

@rthedin
Copy link
Collaborator Author

rthedin commented Jul 22, 2024

I don't think I ever came up with a fix. I'm not sure what my workaround was at the time of the original posting. I don't think this used to happen very frequently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants