The running result of amrMakeDualMesh is incorrect on the windows (MSVC) platform. #1
Description
When compiling and running amrMakeDualMesh on the Windows platform, it was found that there were a lot of missing results. The size of the output umesh and cubes files is much smaller than the correct (compiled and run on the Linux platform) generated results.
After investigation, the main reason is: makeDual.cpp needs to explicitly specify to read the file:
std::ifstream in_cells(cellsFileName, std::iostream::binary) in binary mode;
The possible secondary reason is that under high memory usage, if the Windows kernel writes a large amount of data at once, the system may not be able to lock enough consecutive physical pages (DMA lock failure), causing the I/O operation to be directly rejected by the operating system, causing subsequent files to directly become 0KB. One possible solution is to have the program output in chunks:
` void extractBricks(int level,
const std::vector& cubes,
const std::string& outFileName
)
{
std::string fileName = outFileName + "_" + std::to_string(level) + ".cubes";
std::ofstream out(fileName, std::ios::binary);
PING;
PRINT(level);
std::cout << "Saving level-" << level << " cubes to " << fileName << "; Cubes num = " << cubes.size() << std::endl;
#ifdef _WIN32
const char* ptr = (const char*)cubes.data();
size_t totalBytes = cubes.size() * sizeof(cubes[0]);
const size_t CHUNK_SIZE = 1024ULL * 1024ULL * 1024ULL;
size_t bytesWritten = 0;
while (bytesWritten < totalBytes) {
size_t toWrite = std::min(CHUNK_SIZE, totalBytes - bytesWritten);
out.write(ptr + bytesWritten, toWrite);
if (!out.good()) {
std::cerr << "ERROR: File write failed at offset " << bytesWritten << " bytes!" << std::endl;
break;
}
bytesWritten += toWrite;
}
#else
out.write((char*)cubes.data(), cubes.size() * sizeof(cubes[0]));
#endif // _WIN32
std::cout << "...done" << std::endl;
}`
After the above modifications, I got the correct generation results on the data set containing 333.3M cells, and the correct umesh results on the exajet data set, but there are still errors in the cubes files (umesh_3.cubes is incomplete, umesh_4.cubes is empty file, umesh_5.cubes is correct, umesh_6.cubes is empty file); this is strange, and the reason is not clear yet.
The above test was run on a Windows 11 platform with 64GB RAM and compiled using MSVC.