-
Notifications
You must be signed in to change notification settings - Fork 23
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
min_extents and max_extents mangled with Python interface #378
Comments
Hmmm...I am unable to duplicate on python 2 or 3 using If it is practical, can you attach your |
Your example seems to work fine for me. Do you have anything with a I've attached a small example that reproduces my issue. (Interestingly, instead of a tuple for When I perform the conversion and inspect with my example, I see:
|
Sure. Thats a good hint. Lemme go try a database that has a quadmesh. |
Ok, thanks. That was it. I am duplicating the issue now. Looks like a bug in the python driver code. As a work-around, you can write the extents as raw data to the file and after you read back the mesh itself (with the bad extents), you can then overwrite those values with the raw data extents you wrote to the file separately. Does that make sense? Its non-ideal but this is a clear bug that won't be fixed until you have the next release of Silo...or the patch I commit that you can build from. |
I think I understand. Basically, doing:
Something like that? |
I don't think I mean that quite. What I mean is use...
Then on readback, do this...
So, on read back, you initially get bad data back in the mesh for min/max extents but then you go read the data you wrote to the file to correct that. Of course, |
Ah, ok, but in this case there's a downstream code that is going to be reading the Silo file and looking at the |
Well, yeah, that is correct. I looked and the problem is in the python writer code. So, the file itself has garbage data for these values. If you are reading through the C interface in the downstream code, the caller will get garbage data for those extents. If you are reading throug the python interface in the downstream code, its a couple of extra lines to "patch up" the problem. Lets see...I can think of another approach that would fix the written file...using h5py to overwrite the values stored in the file. That way, anything downstream will be none the wiser. Again, this is all just a work-around before I get the Silo code fixed. I can probably get you a patch you could try by the end of the week. |
You could also use Silo's browser tool to do that...its probably easier that way...have the python code turn around and exec a shell command using browser that fixes those extents in the written file before you give it to anyone. I will demonstrate with an example shortly. |
Sorry..I have been delayed with other fires. Hope to reply by tomorrow. |
I am noticing if you switch to the PDB driver, the issue is not happening. Can you do that? |
Ok, here is the code I was trying to make work. I generalized it a bit from what you had. But, this is how you could correct the created file using
|
Ok, I figured out how to do it same with
|
I'm attempting to use the Python interface to write a new Silo file that contains modifications to an existing Silo file. I'm using Python 3.11 and Silo 4.11.1. My code looks something like the following:
When I inspect the input and output data sets, for the
min_extents
andmax_extents
metadata, I see:Is there a way to preserve
min_extents
andmax_extents
data?The text was updated successfully, but these errors were encountered: