Re: [Paraview] Paraview crashes with netCDF
Thanks. I actually just created a ticket also, a few minutes after you did: https://gitlab.kitware.com/paraview/paraview/issues/17174 I’ll close mine since it is redundant with yours. -- Adam From: "Moreland, Kenneth" <kmo...@sandia.gov> Date: Monday, February 13, 2017 at 4:01 PM To: Dershowitz Adam <adershow...@exponent.com>, "ParaView@paraview.org" <ParaView@paraview.org> Subject: Re: [Paraview] Paraview crashes with netCDF Adam, Was able to replicate your problem. It looks like there are minor issues with both gdalwarp and ParaView that together are causing the crash. The first problem is that gdalwarp is not writing the units attribute correctly when outputting the coordinates in feet. Instead, the units are set to an empty string. This seems wrong. The attribute should be set to “ft” or “feet”. When you use gdalwarp to write units of meters, it correctly writes this attribute as “m”. This is probably a bug, but it shouldn’t cause ParaView to crash. So you probably already see where this is going. NetCDF attributes of empty strings are odd, and the ParaView reader probably has never encountered one before. Lo and behold in this case the reader tries to pull a pointer out of an empty std::string, and std::string throws an exception. I’ve raised a bug for ParaView (https://gitlab.kitware.com/paraview/paraview/issues/17173<https://urldefense.proofpoint.com/v2/url?u=https-3A__gitlab.kitware.com_paraview_paraview_issues_17173=DwMGaQ=t0wRGL5ICVzH157W8C8Wew=5usL3OGqXabRLtSzGmh8YEvbco28TaiOmWcn6rCn8wM=u32SrVyuUNaoi48csYyFS2kh40P7XFwQINDUSttSej4=9gefX6ys8o9uDqRlJV0OmYf7KL3Dyq6bCpq_jGD9yTE=>) and will look into fixing this. I’ll leave it up to you whether you want to contact the GDAL developers about the issue with gdalwarp. -Ken From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Adam Dershowitz Sent: Monday, February 13, 2017 9:20 AM To: ParaView@paraview.org Subject: [EXTERNAL] Re: [Paraview] Paraview crashes with netCDF I found a bit more information. When pareview crashes, here is part of the crash log: Application Specific Information: terminating with uncaught exception of type std::out_of_range: basic_string abort() called Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x7fffcb43add6 __pthread_kill + 10 1 libsystem_pthread.dylib 0x7fffcb526787 pthread_kill + 90 2 libsystem_c.dylib 0x7fffcb3a0420 abort + 129 3 libc++abi.dylib 0x7fffc9efb85a abort_message + 266 4 libc++abi.dylib 0x7fffc9f20c37 default_terminate_handler() + 243 5 libobjc.A.dylib 0x7fffcaa2af33 _objc_terminate() + 124 6 libc++abi.dylib 0x7fffc9f1dd69 std::__terminate(void (*)()) + 8 7 libc++abi.dylib 0x7fffc9f1d9f2 __cxa_rethrow + 99 8 QtCore 0x00010db17d2d QEventLoop::exec(QFlags) + 845 9 QtCore 0x00010db1ad97 QCoreApplication::exec() + 199 10 org.paraview.ParaView 0x00010b083fd2 main + 386 11 libdyld.dylib 0x7fffcb30c255 start + 1 Any idea why that happens with one feet, but not meters in an otherwise identical file? -- Adam From: Dershowitz Adam <adershow...@exponent.com<mailto:adershow...@exponent.com>> Date: Tuesday, February 7, 2017 at 11:58 AM To: "ParaView@paraview.org<mailto:ParaView@paraview.org>" <ParaView@paraview.org<mailto:ParaView@paraview.org>> Subject: Paraview crashes with netCDF I have a geotiff file that I want to view in Paraview. But, Paraview seems to not show the correct offset (0,0 instead of respected the offset). The work around I have been trying is to warp it to the correct location using gdalwarp and to export it as a netCDF. Then Paraview should be able to show it correctly. But, I have run into a crash. If I do this: gdalwarp -t_srs EPSG:3652 -of netCDF test.tiff test_ft.nc then I try to open test.nc in Paraview immediately crashes. While, instead if do this: gdalwarp -t_srs EPSG:3651 -of netCDF test.tiff test_m.nc then it opens fine. The difference between these two files is that EPSG 3652 uses feet (which is better for me, for this particular project) while 3651 uses meters. Both appear to be valid NetCDF files. I’ve tried both readers “CAM NetCDF (Unstructured)” and “NetCDF files generic and CF conventions” with the same results. I’m running Paraview 5.2.0 64-bit on Mac OS 10.12.3. But, I have seen identical results on an older Mac with a prior OS. I had also tried an older version of Paraview with the same result. Any ideas why this consistently crashes Paraview, or what to do about it? Using netCDF was already a work around, and I willing to try others to view these files. The offset and scale are important because I t
Re: [Paraview] Paraview crashes with netCDF
Adam, Was able to replicate your problem. It looks like there are minor issues with both gdalwarp and ParaView that together are causing the crash. The first problem is that gdalwarp is not writing the units attribute correctly when outputting the coordinates in feet. Instead, the units are set to an empty string. This seems wrong. The attribute should be set to “ft” or “feet”. When you use gdalwarp to write units of meters, it correctly writes this attribute as “m”. This is probably a bug, but it shouldn’t cause ParaView to crash. So you probably already see where this is going. NetCDF attributes of empty strings are odd, and the ParaView reader probably has never encountered one before. Lo and behold in this case the reader tries to pull a pointer out of an empty std::string, and std::string throws an exception. I’ve raised a bug for ParaView (https://gitlab.kitware.com/paraview/paraview/issues/17173) and will look into fixing this. I’ll leave it up to you whether you want to contact the GDAL developers about the issue with gdalwarp. -Ken From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Adam Dershowitz Sent: Monday, February 13, 2017 9:20 AM To: ParaView@paraview.org Subject: [EXTERNAL] Re: [Paraview] Paraview crashes with netCDF I found a bit more information. When pareview crashes, here is part of the crash log: Application Specific Information: terminating with uncaught exception of type std::out_of_range: basic_string abort() called Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x7fffcb43add6 __pthread_kill + 10 1 libsystem_pthread.dylib 0x7fffcb526787 pthread_kill + 90 2 libsystem_c.dylib 0x7fffcb3a0420 abort + 129 3 libc++abi.dylib 0x7fffc9efb85a abort_message + 266 4 libc++abi.dylib 0x7fffc9f20c37 default_terminate_handler() + 243 5 libobjc.A.dylib 0x7fffcaa2af33 _objc_terminate() + 124 6 libc++abi.dylib 0x7fffc9f1dd69 std::__terminate(void (*)()) + 8 7 libc++abi.dylib 0x7fffc9f1d9f2 __cxa_rethrow + 99 8 QtCore 0x00010db17d2d QEventLoop::exec(QFlags) + 845 9 QtCore 0x00010db1ad97 QCoreApplication::exec() + 199 10 org.paraview.ParaView 0x00010b083fd2 main + 386 11 libdyld.dylib 0x7fffcb30c255 start + 1 Any idea why that happens with one feet, but not meters in an otherwise identical file? -- Adam From: Dershowitz Adam <adershow...@exponent.com<mailto:adershow...@exponent.com>> Date: Tuesday, February 7, 2017 at 11:58 AM To: "ParaView@paraview.org<mailto:ParaView@paraview.org>" <ParaView@paraview.org<mailto:ParaView@paraview.org>> Subject: Paraview crashes with netCDF I have a geotiff file that I want to view in Paraview. But, Paraview seems to not show the correct offset (0,0 instead of respected the offset). The work around I have been trying is to warp it to the correct location using gdalwarp and to export it as a netCDF. Then Paraview should be able to show it correctly. But, I have run into a crash. If I do this: gdalwarp -t_srs EPSG:3652 -of netCDF test.tiff test_ft.nc then I try to open test.nc in Paraview immediately crashes. While, instead if do this: gdalwarp -t_srs EPSG:3651 -of netCDF test.tiff test_m.nc then it opens fine. The difference between these two files is that EPSG 3652 uses feet (which is better for me, for this particular project) while 3651 uses meters. Both appear to be valid NetCDF files. I’ve tried both readers “CAM NetCDF (Unstructured)” and “NetCDF files generic and CF conventions” with the same results. I’m running Paraview 5.2.0 64-bit on Mac OS 10.12.3. But, I have seen identical results on an older Mac with a prior OS. I had also tried an older version of Paraview with the same result. Any ideas why this consistently crashes Paraview, or what to do about it? Using netCDF was already a work around, and I willing to try others to view these files. The offset and scale are important because I then need to put in other data that is in the correct location and units. The files are too big for me to send to the mailing list, so I have not posted them. Thanks, -- Adam ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Search the list archives at: http://markmail.org/search/?q=ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
Re: [Paraview] Paraview crashes with netCDF
I found a bit more information. When pareview crashes, here is part of the crash log: Application Specific Information: terminating with uncaught exception of type std::out_of_range: basic_string abort() called Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x7fffcb43add6 __pthread_kill + 10 1 libsystem_pthread.dylib 0x7fffcb526787 pthread_kill + 90 2 libsystem_c.dylib 0x7fffcb3a0420 abort + 129 3 libc++abi.dylib 0x7fffc9efb85a abort_message + 266 4 libc++abi.dylib 0x7fffc9f20c37 default_terminate_handler() + 243 5 libobjc.A.dylib 0x7fffcaa2af33 _objc_terminate() + 124 6 libc++abi.dylib 0x7fffc9f1dd69 std::__terminate(void (*)()) + 8 7 libc++abi.dylib 0x7fffc9f1d9f2 __cxa_rethrow + 99 8 QtCore 0x00010db17d2d QEventLoop::exec(QFlags) + 845 9 QtCore 0x00010db1ad97 QCoreApplication::exec() + 199 10 org.paraview.ParaView 0x00010b083fd2 main + 386 11 libdyld.dylib 0x7fffcb30c255 start + 1 Any idea why that happens with one feet, but not meters in an otherwise identical file? -- Adam From: Dershowitz Adam <adershow...@exponent.com> Date: Tuesday, February 7, 2017 at 11:58 AM To: "ParaView@paraview.org" <ParaView@paraview.org> Subject: Paraview crashes with netCDF I have a geotiff file that I want to view in Paraview. But, Paraview seems to not show the correct offset (0,0 instead of respected the offset). The work around I have been trying is to warp it to the correct location using gdalwarp and to export it as a netCDF. Then Paraview should be able to show it correctly. But, I have run into a crash. If I do this: gdalwarp -t_srs EPSG:3652 -of netCDF test.tiff test_ft.nc then I try to open test.nc in Paraview immediately crashes. While, instead if do this: gdalwarp -t_srs EPSG:3651 -of netCDF test.tiff test_m.nc then it opens fine. The difference between these two files is that EPSG 3652 uses feet (which is better for me, for this particular project) while 3651 uses meters. Both appear to be valid NetCDF files. I’ve tried both readers “CAM NetCDF (Unstructured)” and “NetCDF files generic and CF conventions” with the same results. I’m running Paraview 5.2.0 64-bit on Mac OS 10.12.3. But, I have seen identical results on an older Mac with a prior OS. I had also tried an older version of Paraview with the same result. Any ideas why this consistently crashes Paraview, or what to do about it? Using netCDF was already a work around, and I willing to try others to view these files. The offset and scale are important because I then need to put in other data that is in the correct location and units. The files are too big for me to send to the mailing list, so I have not posted them. Thanks, -- Adam ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Search the list archives at: http://markmail.org/search/?q=ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
[Paraview] Paraview crashes with netCDF
I have a geotiff file that I want to view in Paraview. But, Paraview seems to not show the correct offset (0,0 instead of respected the offset). The work around I have been trying is to warp it to the correct location using gdalwarp and to export it as a netCDF. Then Paraview should be able to show it correctly. But, I have run into a crash. If I do this: gdalwarp -t_srs EPSG:3652 -of netCDF test.tiff test_ft.nc then I try to open test.nc in Paraview immediately crashes. While, instead if do this: gdalwarp -t_srs EPSG:3651 -of netCDF test.tiff test_m.nc then it opens fine. The difference between these two files is that EPSG 3652 uses feet (which is better for me, for this particular project) while 3651 uses meters. Both appear to be valid NetCDF files. I’ve tried both readers “CAM NetCDF (Unstructured)” and “NetCDF files generic and CF conventions” with the same results. I’m running Paraview 5.2.0 64-bit on Mac OS 10.12.3. But, I have seen identical results on an older Mac with a prior OS. I had also tried an older version of Paraview with the same result. Any ideas why this consistently crashes Paraview, or what to do about it? Using netCDF was already a work around, and I willing to try others to view these files. The offset and scale are important because I then need to put in other data that is in the correct location and units. The files are too big for me to send to the mailing list, so I have not posted them. Thanks, -- Adam ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Search the list archives at: http://markmail.org/search/?q=ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
