You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The write_model_UBC for TensorMesh and TreeMesh do not work properly for UBC-GIF active cells models. In SimPEG, active cells are a boolean array, which cannot be written directly. For UBC-GIF, they are binary values. Even if you convert the SimPEG boolean array to dtype=int, write_model_UBC will write the values in scientific notation.
Suggestion
Make write_active_cells_UBC and read_active_cells_UBC. I think its clearer to separate from write_model_UBC and read_model_UBC. However, I think we can get each to call a core piece of functionality smart enough to handle either.
What point do the `write_model_UBC’ style functions change the dtype of the array?
If I first convert from a boolean array to int array, it happen when calling np.savetxt, since it uses the default format option. This is something that could be changed. If you want the least amount of change to the code, we could add code which 1) checks to see if the array is a boolean array, then 2) convert to 0s and 1s, then 3) writes with the proper formatting. Do you want to do that?
I just keep running into this as I move between SimPEG and UBC-GIF stuff
Activity
jcapriot commentedon Jun 25, 2026
What point do the `write_model_UBC’ style functions change the dtype of the array?
dccowan commentedon Jun 25, 2026
If I first convert from a boolean array to int array, it happen when calling np.savetxt, since it uses the default format option. This is something that could be changed. If you want the least amount of change to the code, we could add code which 1) checks to see if the array is a boolean array, then 2) convert to 0s and 1s, then 3) writes with the proper formatting. Do you want to do that?
I just keep running into this as I move between SimPEG and UBC-GIF stuff
jcapriot commentedon Jun 25, 2026
Ah, I see... Maybe then we should just do a format string that depends on the dtype of the input:
dccowan commentedon Jun 25, 2026
That's probably the easiest fix. I'm happy to do this.
jcapriot commentedon Jun 25, 2026
Would it also be helpful to add a ‘dtype’ option to the corresponding read in values as well that forces a data type on `np.loadtxt’?