-
Notifications
You must be signed in to change notification settings - Fork 9
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
Fix usage of change_tagToMesh/change_tagTorc #32
Comments
Looking at the unmap code I'm wondering why we don't directly store the I'm guessing it's due to a check on adding a tag that requires that adding a tag be of a certain size that corresponds to the number of nodes. In that case, why don't we just store the I suspect/hope that the user/application code isn't relying on the I will finish getting things functional as is and then submit a pull request to review with these refactors. |
Hi @jacobmerson , we do directly store the |
I think I understand...essentially, the field transfer (and writing procedures) require data in I'm hitting a bug where the size of the arrays are not getting reset. I'm going to try a different approach and see if that can get over the hump. |
okay, sounds good. This is not required in any way but if you have the
time, it might be helpful to log the output of rc-test failure with this
issue
|
The error after merging was a failure here. The data looked correct but the array sizes were getting messed up after the write to file here. I suspected that it's somehow an issue with the tag swapping for a while and then I thought it was just an unmatched conversion, but doesn't seem to be. You can find the merge with the broken unit tests and some debug outputs here. As I mentioned earlier. I'm refactoring a bit such that we store the tags in rc format but not in the tags vector of the mesh. Then everywhere possible we work with the rc arrays rather than using tags. I haven't dug into it yet, but as you say we may need the mesh tags for adaption. If so, there is still the same Torc function, but now it works slightly different under the hood. |
@joshia5 is there a reason that the |
I don't follow. |
|
Fixed in 7dbcd10 |
There is a pattern in the vtk writer and unmap where the
write_array
function is surrounded by calls tochange_tagToMesh
andchange_tagTorc
.There is a change in the
set_tags
function which makes it invalidate a pointer to the old tag when the array gets swapped. So, usingchange_tagToMesh
/change_tagTorc
has become silently dangerous because of the tag invalidation.I'm not exactly sure what the difference in the formats is, but it seems as though the baseline storage of the reverse classification on the mesh should be in the "rc" format and it's just converted to the mesh format to write it out or do whatever
unmap
does.@joshia5 I'd like to get your opinion on the following change because it seems that it will save some work/memory.
_rc
tags in "rc" format (looks like this is currently the intent)change_tagToMesh
andchange_tagTorc
rc_tag_to_mesh_array
which returns the rc tag array in the "mesh" format.The text was updated successfully, but these errors were encountered: