I thought the same thing. I’m having a similar problem and wonder if using relative paths would fix it.
Although in my case, I tried using “Change file” for the input files and that also didn’t resolve anything so I’m at a loss.
Edit: I’m no longer at as much of a loss. Choosing “use file under specified directory” when loading the state file appears to be an adequate workaround.
Please share your state file, data and actual error.
Thank you @mwestphal,
Here is the state file and input files referenced therein: (1.9 MB)
The state file was created on a MacOS 14.5 machine in Paraview 5.13. Then here’s the errors that show when I attempt to open it on a MacOS 14.4 in Paraview 5.13.
Errors (3.4 KB)
Notably:
vtkXMLUnstructuredGridReader (0x7fe347050930): Error opening file /Users/haiiro/Library/CloudStorage/Dropbox/Research/2024_ucla_pujan_potential_data/output_substrate_atoms.vtu
On the source machine the path in question is /Users/haiiro/Library/CloudStorage/Dropbox/Research/2024_ucla_pujan_potential_data/output_substrate_atoms.vtu.
And on the destination machine where errors are thrown, it’s /Users/haiiro/Dropbox/Research/2024_ucla_pujan_potential_data/output_substrate_atoms.vtu.
I’m not sure why the (rougly) same macOS version of Dropbox uses a different directory on the source and destination machines, but that’s where the discrepency is. Previously, I had enjoyed the simplicity of having mirrored directory structures, but at the moment they deviate.
As I mentioned in the edit in my OP, choosing “use file under specified directory” when loading the state file appears to be an adequate workaround, but storing input file paths relative to the state file would also be a good solution in my opinion.
Indeed, this is not supported by the state file mechanism, but it could be. You may want to open an issue: https://gitlab.kitware.com/paraview/paraview/-/issues