Open VDS issueshttps://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues2024-02-29T07:29:59Zhttps://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/232Build fails if curl is preinstalled (Alpine Linux)2024-02-29T07:29:59ZAlexander JaustBuild fails if curl is preinstalled (Alpine Linux)The linking step of OpenVDS and its executables fails if cURL is preinstalled on the system and OpenVDS builds its own cURL as well. I have attached a [Dockerfile](/uploads/3caea214874b12856dc12bfc7755bb7e/broken-openvds-build.dockerfile...The linking step of OpenVDS and its executables fails if cURL is preinstalled on the system and OpenVDS builds its own cURL as well. I have attached a [Dockerfile](/uploads/3caea214874b12856dc12bfc7755bb7e/broken-openvds-build.dockerfile) to reproduce the error. It seems that CMake picks up a different cURL or some other dependency which pulls in `libidn2`.
Do you have any idea what causes this?
```text
[...]
[ 96%] Linking CXX executable VDSCopy
cd /open-vds/build/tools/VDSCopy && /usr/bin/cmake -E cmake_link_script CMakeFiles/VDSCopy.dir/link.txt --verbose=1
/usr/bin/c++ -O3 -DNDEBUG -s -Wl,--exclude-libs=ALL -Wl,--no-export-dynamic CMakeFiles/VDSCopy.dir/VDSCopy.cpp.o ../Shared/CMakeFiles/tools_shared.dir/HelpConnection.cpp.o -o VDSCopy -Wl,-rpath,/open-vds/build/src/OpenVDS: ../../src/OpenVDS/libopenvds.so.3.4.255 ../../fmt_9.1.0/lib
fmt.a ../../jsoncpp_1.8.4/src/lib_json/libjsoncpp_static.a ../../docs/libhelp_connection.a
/usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: ../../src/OpenVDS/libopenvds.so.3.4.255: undefined reference to `idn2_lookup_ul'
/usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: ../../src/OpenVDS/libopenvds.so.3.4.255: undefined reference to `idn2_check_version'
/usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: ../../src/OpenVDS/libopenvds.so.3.4.255: undefined reference to `idn2_strerror'
/usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: ../../src/OpenVDS/libopenvds.so.3.4.255: undefined reference to `idn2_free'
collect2: error: ld returned 1 exit status
```
## Operating system
Alpine Linux (latest), but problem seems to appear starting from Alpine Linux 3.18. It builds fine in Alpine Linux 3.17.
I tested in Docker on an M1 Mac with and without x86_64 emulation. The error shows up in both cases.
## What did I try
### Without success
- Enabled/disabled different I/O managers.
- Had a look into the CMake files, but I must admit that I do not know how to properly debug this.
- Installing `libidn2-dev` , but it seems to be present already if one installs `curl-dev`.
- Switching between Make and Ninja as build system
### Successfully
- Setting `-DBUILD_CURL=OFF` seems to fix the problem. However, I am not sure if this has implications for features or performance.https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/2Build Fixes for Fedora 312019-12-20T08:46:37ZAndrew KBuild Fixes for Fedora 31Add this as an issue since I don't appear to have access to submit a merge request.
I ran into a few problem when trying to build OpenVDS in Fedora 31. I've fixed the issues locally and have submitted my patch file for the master branch...Add this as an issue since I don't appear to have access to submit a merge request.
I ran into a few problem when trying to build OpenVDS in Fedora 31. I've fixed the issues locally and have submitted my patch file for the master branch get rid of the problems. These should still be ok for other distributions as well
[openvds_build.diff](/uploads/46da01da49937d8912060330583602de/openvds_build.diff)
- Set CMAKE_INSTALL_LIBDIR to lib${LIBSUFFIX} for Azure Storage SDK
* Azure Storage SDK does not use GNUInstallDir cmake include to
set the CMAKE_INSTALL_<dir> variables resulting in invalid LIBDIR
paths for distributions that use lib64. However, they provide a way
to override it which is what this change uses to set the correct path
- Add WERROR=OFF for cpprestsdk
* Warning about deprecated-copy when building with gcc 9. Causes
the build to fail if werror is enabled
- Remove const from dimensionDistribution
* uniform_real_distribution<float> call operator is not const which
causes an error when building with gcc 9https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/226Building from source2024-01-29T08:38:09ZVasilii SinkevichBuilding from sourceHi,
I am trying to build the static library from the source code and as a first step I did compile dynamically as instructed and noticed that Wavelet compression is not supported in the resulting library - just checked with OpenVDS::Is...Hi,
I am trying to build the static library from the source code and as a first step I did compile dynamically as instructed and noticed that Wavelet compression is not supported in the resulting library - just checked with OpenVDS::IsCompressionMethodSupported(OpenVDS::CompressionMethod::Wavelet).
Is it how it is supposed to be or I did something wrong?
Does it mean that both compression/decompression is not supported or decompression will still be working?
Thanks you,
Vasiliihttps://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/96Building out of the box2021-12-09T02:37:33ZPaal KvammeBuilding out of the boxBuilding using docker/*.Dockerfile doesn't work out of the box. Not for me at least. Here is a list of some bugs and some annoyances. I am using the dockerfiles in the baseline but not the actual build scripts.
docker/centos8.Dockerfile...Building using docker/*.Dockerfile doesn't work out of the box. Not for me at least. Here is a list of some bugs and some annoyances. I am using the dockerfiles in the baseline but not the actual build scripts.
docker/centos8.Dockerfile:
- Need to rename PowerTools -> powertools (upstream change in CentOS 8)
- Building C++ "Release" causes several unit tests to crash. Need to use RelWithDebug, and copy the results to where a Release build would have put them.
- Note that boost 1.6.9 is installed in the docker image but not used, unless BOOST_INCLUDEDIR and BOOST_LIBRARYDIR is manually set.
- Note that Release libraries are installed to lib/ while Debug libraries are below lib64. Long live consistency.
- Need to edit the dockerfile to also install python3-devel to get the wheel built. I used "python3 setup.py --build-type RelWithDebug bdist_wheel" to do the actual build. Later attempts also disabled AWS, AZURE, etc.
- The Python wheel still didn't work for CentOS 8, even after fixing things so Python was found. Reason: Since I had to use "RelWithDebug" for the C++ API I assumed the same applied to Python. Not so. In fact, "RelWithDebug" silently fails in that case. The wheel, while created, is still incomplete.
docker/centos7.Dockerfile:
- The dockerfile installs devtoolset-8 while the build script tries to use devtoolset-7.
docker/ubuntu-20.04.Dockerfile:
- dlopen() and dlclose missing. Add the following to src/OpenVDS/CMakeLists.txt. Only needed for Ubuntu, but it appears to be harmless to do it for all. ```target_link_libraries(openvds_objects PRIVATE ${CMAKE_DL_LIBS})```
- Python is not found, need to edit CMakeLists.txt look for Python3 and replace Development.Module with just Development. Note, I applied this to CentOS as well but I have not verified that it was needed there.
All:
- When building sdapi (dms) on Linux, the library ends up as libsdapi.so.0.0 instead of the version (3.14 currently) found in src/src/core/SDVersion.h. Either the OpenVDS build is not using the devops/scripts/build-linux64.sh script (which does sound likely) or there is some problem with some of the other rules. The "0.0" version causes problems if an application uses both OpenVDS and some other module using sdapi.
- When something goes wrong building the Python wheel it is not obvious that there is a problem. I use "python3 setup.py bdist_wheel". Later attempts also disabled AWS, AZURE, etc. The wheel gets created but it is missing key files. Trying to install the wheel and import it gives an error about openvds core not available. Buried somewhere in the build logs I see a message about "Cannot find Python3, found version 3.6.8. Which is itself pretty confusing. It sounds like, "I found it, but I didn't find it". What to do with such errors is not obvious.https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/144Build OpenVDS+ with the latest msvc 20222022-09-26T09:44:53ZArtem ВBuild OpenVDS+ with the latest msvc 2022Can you provide information about msvc complier version of openvds+ (2.4.3) build?
`msvc_140` - it is actual msvc toolset, isn't it?
Do you have any plans to migrate to newly msvc (2022) and update dlls?Can you provide information about msvc complier version of openvds+ (2.4.3) build?
`msvc_140` - it is actual msvc toolset, isn't it?
Do you have any plans to migrate to newly msvc (2022) and update dlls?https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/139Build Open VDS with the new version of seismic-cpp-lib2022-09-08T12:14:19ZYan Sushchynski (EPAM)Build Open VDS with the new version of seismic-cpp-libCould I ask you to build Open VDS convertor with using the latest sdapi version with Anthos support?
SDAPI Anthos MR:
https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-cpp-li...Could I ask you to build Open VDS convertor with using the latest sdapi version with Anthos support?
SDAPI Anthos MR:
https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/seismic-dms-suite/seismic-store-cpp-lib/-/merge_requests/147M14 - Release 0.17Morten OfstadJørgen Lindjorgen.lind@3lc.aiMorten Ofstadhttps://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/162Byte swap bug in Ibm2ieee2023-06-20T12:16:12ZArtem ВByte swap bug in Ibm2ieeeWe found that `Ibm2ieee` implementation does not take into account file and host endianness.
For example:
```
template<SEGY::Endianness ENDIANNESS, SEGY::BinaryHeader::DataSampleFormatCode FORMAT>
void copySamples(float * prTarget, con...We found that `Ibm2ieee` implementation does not take into account file and host endianness.
For example:
```
template<SEGY::Endianness ENDIANNESS, SEGY::BinaryHeader::DataSampleFormatCode FORMAT>
void copySamples(float * prTarget, const unsigned char * puSource, int iSampleMin, int iSampleMax)
{
if (ENDIANNESS == SEGY::Endianness::BigEndian)
{
nValue = (int)(puSource[iSample * 4 + 0] << 24 | puSource[iSample * 4 + 1] << 16 | puSource[iSample * 4 + 2] << 8 | puSource[iSample * 4 + 3]);
}
else
{
nValue = (int)(puSource[iSample * 4 + 3] << 24 | puSource[iSample * 4 + 2] << 16 | puSource[iSample * 4 + 1] << 8 | puSource[iSample * 4 + 0]);
}
}
```
use native conversion with real file endianess.
The original 'Ibm2ieee' form SEGY.cpp always swaps bytes:
```
template<SEGY::Endianness ENDIANNESS, SEGY::BinaryHeader::DataSampleFormatCode FORMAT>
void copySamples(float * prTarget, const unsigned char * puSource, int iSampleMin, int iSampleMax)
{
if (FORMAT == SEGY::BinaryHeader::DataSampleFormatCode::IBMFloat)
{
SEGY::Ibm2ieee(prTarget, puSource + iSampleMin * 4, iSampleMax - iSampleMin);
return;
}
}
void ibm2ieee(void * to, const void * from, size_t len)
{
...
#ifdef WIN32
fr = _byteswap_ulong(fr);
#else
fr = __builtin_bswap32(fr);
#endif // WIN32
...
}
```
It is needed to check real file and hosts endianess before swap bytes.
---
It makes wrong traces data for little-endian SEG-Ys with IBMFloats data formathttps://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/153Cannot create IJKCoordinateTransformer for 2D dataset (Python)2022-10-31T14:31:13ZAlexander JaustCannot create IJKCoordinateTransformer for 2D dataset (Python)## Description
I am currently playing around with the creation of VDS files. I am especially interested in working via the Python interface and the different coordinate systems. I set up the a small [Python script](/uploads/8d79d553af1f...## Description
I am currently playing around with the creation of VDS files. I am especially interested in working via the Python interface and the different coordinate systems. I set up the a small [Python script](/uploads/8d79d553af1f908973720a1e03b21e06/write_2d_vds_data_testing.py) that creates a simple 2D dataset from a NumPy array with random content. Parts of the script is based on the `npz_to_vds.py` script from the examples. I would like to convert between inline/crossline coordinates, voxel coordinates and world coordinates.
In my script, the creation of the VDS file is successful. I also see that the file is recognized as 2D file by OpenVDS during writing since the chunks written to the page buffer are 4*brick_size. However, when I want to obtain the `IJKCoordinateTransformer` for this file, I run into the following exception
```text
Exception:
Dimension -1 is not a valid dimension. Dimensionality_Max is 6.
```
When I create a 3D file with only one coordinate in z direction, obtaining the transformer seems to be successful.
## Expectation
I obtain the coordinate transformer which allows me to transform between [different coordinate](https://osdu.pages.opengroup.org/platform/domain-data-mgmt-services/seismic/open-vds/cppdoc/struct/structOpenVDS_1_1IJKCoordinateTransformer.html) systems (ijk, inline/crossline etc.).
## Questions
- Is this behavior expected? I assumed that I could still work with the IJK transformer.
- Do I create the file as a 2D file in a wrong way?
- If the behavior is expected, would it be possible to extend the transformer to work with 2D data and/or as a quick fix to make the error message more expressive?
## System
- Arm64 MacOS 12.6
- VDS 3.0.3 with Python interfacehttps://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/70Can not create OpenVDS container in file.2021-03-11T13:23:52ZAnatoly YanchevskyCan not create OpenVDS container in file.In latest version: 1.2.0
When I try to work with OpenVDS as file, I got assert in:
HueBulkDataStore::FileInterface *
HueBulkDataStoreImpl::AddFile(const char *fileName, int chunkCount, int indexPageEntryCount, int fileType, int chunkMet...In latest version: 1.2.0
When I try to work with OpenVDS as file, I got assert in:
HueBulkDataStore::FileInterface *
HueBulkDataStoreImpl::AddFile(const char *fileName, int chunkCount, int indexPageEntryCount, int fileType, int chunkMetadataLength, int fileMetadataLength, bool overwriteExisting)
{
assert(!m_readOnly && m_extentAllocator);
this occur because in `urlToOpenOptions` missing `&removeProtocol` for file protocol.https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/52Cannot create VDSs with the Java API2021-08-31T13:57:59ZMorten OfstadCannot create VDSs with the Java APIJava API is missing create() calls and there might be other missing pieces needed to create a new VDS from scratch.Java API is missing create() calls and there might be other missing pieces needed to create a new VDS from scratch.https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/166Cannot import openvds with Python 3.112023-01-03T12:43:01ZDavid WadeCannot import openvds with Python 3.11There is definitely something very wrong when attempting to import openvds on Python 3.11
Please fix?
```
Collecting openvds
Downloading openvds-3.1.3-cp311-cp311-win_amd64.whl (19.1 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ...There is definitely something very wrong when attempting to import openvds on Python 3.11
Please fix?
```
Collecting openvds
Downloading openvds-3.1.3-cp311-cp311-win_amd64.whl (19.1 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 19.1/19.1 MB 2.3 MB/s eta 0:00:00
Installing collected packages: numpy, openvds
Successfully installed numpy-1.24.1 openvds-3.1.3
(vds-311) PS C:\xxxx\xxxxx\xxxxx> python
Python 3.11.1 (tags/v3.11.1:a7a450f, Dec 6 2022, 19:58:39) [MSC v.1934 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import openvds
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\xxxx\xxxx\vds-311\Lib\site-packages\openvds\__init__.py", line 1, in <module>
from .api import *
File "C:\xxxx\xxxx\vds-311\Lib\site-packages\openvds\api.py", line 18, in <module>
import openvds.core
ModuleNotFoundError: No module named 'openvds.core'
```https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/101Can OpenVDS read old VDS files?2022-01-31T16:08:51ZPaal KvammeCan OpenVDS read old VDS files?From the README.md file:
The specification is based on, but not similar to, the existing Volume Data Store (VDS) file format
So the old VDS and the new OpenVDS are two different file formats, right? Does OpenVDS then support readin...From the README.md file:
The specification is based on, but not similar to, the existing Volume Data Store (VDS) file format
So the old VDS and the new OpenVDS are two different file formats, right? Does OpenVDS then support reading old VDS files?
Or have I misunderstood, and this is just about the "api specification" and that the underlying file format is the same?https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/69Can't build without Google GCS2021-03-08T15:07:57ZCamille PerinCan't build without Google GCSOpenVDS can't build without Google GCS since Dms introduction. This build procedure :
```
cmake -DDISABLE_GCP_IOMANAGER=ON ..
make
```
leads to this error :
```
Scanning dependencies of target sdapi_objects
[ 19%] Building CXX object ...OpenVDS can't build without Google GCS since Dms introduction. This build procedure :
```
cmake -DDISABLE_GCP_IOMANAGER=ON ..
make
```
leads to this error :
```
Scanning dependencies of target sdapi_objects
[ 19%] Building CXX object 3rdparty/BuildDms/CMakeFiles/sdapi_objects.dir/__/dms-c7ba5398/src/src/core/SDDataset.cc.o
[ 20%] Building CXX object 3rdparty/BuildDms/CMakeFiles/sdapi_objects.dir/__/dms-c7ba5398/src/src/core/SDReadOnlyGenericDatasetAccessor.cc.o
[ 20%] Building CXX object 3rdparty/BuildDms/CMakeFiles/sdapi_objects.dir/__/dms-c7ba5398/src/src/core/Constants.cc.o
[ 20%] Building CXX object 3rdparty/BuildDms/CMakeFiles/sdapi_objects.dir/__/dms-c7ba5398/src/src/core/SDException.cc.o
[ 21%] Building CXX object 3rdparty/BuildDms/CMakeFiles/sdapi_objects.dir/__/dms-c7ba5398/src/src/core/SDGenericDataset.cc.o
[ 21%] Building CXX object 3rdparty/BuildDms/CMakeFiles/sdapi_objects.dir/__/dms-c7ba5398/src/src/core/SDHierarchicalDataset.cc.o
[ 21%] Building CXX object 3rdparty/BuildDms/CMakeFiles/sdapi_objects.dir/__/dms-c7ba5398/src/src/core/SDManager.cc.o
[ 22%] Building CXX object 3rdparty/BuildDms/CMakeFiles/sdapi_objects.dir/__/dms-c7ba5398/src/src/core/SDHierarchicalDatasetAccessor.cc.o
[ 22%] Building CXX object 3rdparty/BuildDms/CMakeFiles/sdapi_objects.dir/__/dms-c7ba5398/src/src/core/SDUtils.cc.o
[ 23%] Building CXX object 3rdparty/BuildDms/CMakeFiles/sdapi_objects.dir/__/dms-c7ba5398/src/src/lib/accessors/GcsAccessor.cc.o
/tmp/open-vds/3rdparty/dms-c7ba5398/src/src/lib/accessors/GcsAccessor.cc:29:10: fatal error: crc32c/crc32c.h: Aucun fichier ou dossier de ce type
#include "crc32c/crc32c.h"
^~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [3rdparty/BuildDms/CMakeFiles/sdapi_objects.dir/build.make:180: 3rdparty/BuildDms/CMakeFiles/sdapi_objects.dir/__/dms-c7ba5398/src/src/lib/accessors/GcsAccessor.cc.o] Error 1
make[2]: *** Attente des tâches non terminées....
make[1]: *** [CMakeFiles/Makefile2:782: 3rdparty/BuildDms/CMakeFiles/sdapi_objects.dir/all] Error 2
make: *** [Makefile:163: all] Error 2
```https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/120Can't create VDS handle to read from S3 if remote VDS compressed with Wavelet...2022-06-03T11:07:05ZAlex TCan't create VDS handle to read from S3 if remote VDS compressed with WaveletNormalizeBlock methodHello!
I ran into a problem trying to open remote VDS on S3 compressed using `WaveletNormalizeBlock` method.
**The problem** description: I receive "illegal compression method" error trying to read from that VDS. It looks impossible to...Hello!
I ran into a problem trying to open remote VDS on S3 compressed using `WaveletNormalizeBlock` method.
**The problem** description: I receive "illegal compression method" error trying to read from that VDS. It looks impossible to read from `WaveletNormalizeBlock`-compressed VDS using VDSInfo or any other OpenVDS tool (e.g. slicedump sample), but I thought it is OK to use wavelet-compressed VDS just to read.
Moreover, such a VDS can't be read from even using OpenVDS+ library tools!
Surprisingly, if I use local file-based VDS with `WaveletNormalizeBlock` compression, all works perfectly.
If it's important, I have uploaded such a VDS to S3 using OpenVDS+ utils (SEGYImport/VDSCopy).
As I can see in OpenVDS sources, the reason is that ParseVDSJson.cpp module serializes `CompressionMethod::WaveletNormalizeBlock` enum to string as `"WaveletNormalizeBlock"` inside `std::string ToString(CompressionMethod compressionMethod)` function, but deserialize function `CompressionMethod CompressionMethodFromJson(Json::Value const &jsonCompressionMethod)` has the following code:
static CompressionMethod CompressionMethodFromJson(Json::Value const &jsonCompressionMethod) {
std::string compressionMethodString = jsonCompressionMethod.asString();
...
else if(compressionMethodString == "WaveletNormalizeBlockExperimental") // NOTE THIS
{
return CompressionMethod::WaveletNormalizeBlock;
}
...
else
{
throw Json::Exception("Illegal compression method");
}
}
So strings don't match each other (`"WaveletNormalizeBlock"` != `"WaveletNormalizeBlockExperimental"`) and we run into exception.
**My question** is: isn't this is a bug/typo in source code and can it be fixed? (for OpenVDS+ release too, if I may ask)
Or if this is intended behavior, can you please reveal the reason behind this logic?https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/131Can't remove file segy file after vds conversion2022-08-09T09:56:47ZArtem ВCan't remove file segy file after vds conversionCase:
1. Use original code from openvds SEGYImport
2. Convert any segy to vds - it OK, vds file successfully created.
3. Do not close original app - and try to remove input segy file.
4. Fail - user can't remove input segy while app is o...Case:
1. Use original code from openvds SEGYImport
2. Convert any segy to vds - it OK, vds file successfully created.
3. Do not close original app - and try to remove input segy file.
4. Fail - user can't remove input segy while app is open.
For example:
![image](/uploads/25b2e7105fdfca86afbb59d0776c2a75/image.png)
```
traceDataManagers[fileIndex].addDataRequests(chunkInfo.secondaryKeyStart, chunkInfo.secondaryKeyStop, lower, upper);
->
m_dataViewManager->addDataRequests(requests);
->
prefetchUntilMemoryLimit();
->
auto dataView = std::make_shared<DataView>(m_dataProvider, req.offset, req.size, true, m_error);
```
segy use `win32api file mapping` and seems like ptr not cleared.https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/72Change bricksize defaults when importing with compression2021-03-08T15:07:16ZMorten OfstadChange bricksize defaults when importing with compressionSEGYImport should default to 128 bricksize with 4 margin is using wavelet compression.SEGYImport should default to 128 bricksize with 4 margin is using wavelet compression.https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/193Change in behavior of rare formats after upgrade2023-06-23T11:44:23ZAlena ChaikouskayaChange in behavior of rare formats after upgradeHi!
Some of our tests failed after upgrade to openvds master.
Seems to be caused by commit 560aa68029de532bc2a2b1d1c3d28229fcb9ba7a
Tests which started to fail request data from vds created from SEGY in formats [format3.segy](/uploads/...Hi!
Some of our tests failed after upgrade to openvds master.
Seems to be caused by commit 560aa68029de532bc2a2b1d1c3d28229fcb9ba7a
Tests which started to fail request data from vds created from SEGY in formats [format3.segy](/uploads/9e27a6b840c695d308517d1490bb2574/format3.segy), [format8.segy](/uploads/a8a04f7d69d85464db78c4c0f6fb9f4a/format8.segy), [format11.segy](/uploads/71dc95ca89c5c0e3d7869979d12c3f19/format11.segy), [format16.segy](/uploads/d0673ee9e49f08ed0de338a8bc3e46eb/format16.segy) (signed short 2 byte, signed char 1 byte, unsigned short 2 byte, unsigned char 1 byte) by using RequestVolumeTraces.
Per our previous experience, for all supported format this method returned us data in f4. Requested buffer is in floats, after all.
Now the following code [format.cpp](/uploads/38bf2d7b5adecf75b46bcb5f5e1f881b/format.cpp) produces results like that:
| | old openvds | new openvds |
|--------------|-----------------------------------------|-----------------------------------------------------------------------|
| format3.vds | 100 101 102 103 104 105 106 107 108 109 | -32768 -32768 -32768 -32768 -32768 -32768 -32768 -32768 -32768 -32768 |
| format8.vds | 100 101 102 103 104 105 106 107 108 109 | -128 -128 -128 -128 -128 -128 -128 -128 -128 -128 |
| format11.vds | 100 101 102 103 104 105 106 107 108 109 | 0 0 0 0 0 0 0 0 0 0 |
| format16.vds | 100 101 102 103 104 105 106 107 108 109 | 0 0 0 0 0 0 0 0 0 0 |
Did we as usual make some incorrect assumption or is it a breaking change?
[format16.vds](/uploads/c88014b946188f95c4511e7c517d48dd/format16.vds)
[format11.vds](/uploads/5f012a4590218ba68e27648ed06e30b6/format11.vds)
[format8.vds](/uploads/dc1df019ae30dd4863c67bc06f964b5f/format8.vds)
[format3.vds](/uploads/2a23f1b8f8a0155e9f8e1d69f72c7ab0/format3.vds)https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/43CI should fail on missing new python api2021-06-16T22:19:42ZJørgen Lindjorgen.lind@3lc.aiCI should fail on missing new python apiWhen adding functionality that should update the python bindings, then ci should failWhen adding functionality that should update the python bindings, then ci should failhttps://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/45Compilation fails on centos 7 with recent devtoolset2020-09-01T09:12:54ZMorten OfstadCompilation fails on centos 7 with recent devtoolset> /usr/include/c++/4.8.2/atomic: In instantiation of 'struct std::atomic<std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long int, std::ratio<1l, 1000000000l> > > >':
> /project/open-vds/src/OpenVDS/VDS/Volu...> /usr/include/c++/4.8.2/atomic: In instantiation of 'struct std::atomic<std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long int, std::ratio<1l, 1000000000l> > > >':
> /project/open-vds/src/OpenVDS/VDS/VolumeDataPageAccessorImpl.h:50:67: required from here
> /usr/include/c++/4.8.2/atomic:167:7: error: function 'std::atomic<_Tp>::atomic() [with _Tp = std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long int, std::ratio<1l, 1000000000l> > >]' defaulted on its first declaration with an exception-specification that differs from the implicit declaration 'constexpr std::atomic<std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long int, std::ratio<1l, 1000000000l> > > >::atomic()'
> atomic() noexcept = default;
> ^
>
I don't think we need to use atomic for the m_lastUsed timestamp -- either that or we can just convert it to a plain int64_t which has milliseconds after startup (using the steady_clock).Version 1.0Jørgen Lindjorgen.lind@3lc.aiJørgen Lindjorgen.lind@3lc.aihttps://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-vds/-/issues/19Complete C++ API documentation2020-06-03T14:04:58ZMorten OfstadComplete C++ API documentationCurrently only the VolumeDataAccessManager methods are documented. The documentation needs to be complete and well formatted.Currently only the VolumeDataAccessManager methods are documented. The documentation needs to be complete and well formatted.Morten OfstadMorten Ofstad