BANDIT crash on Windows (MSYS+CMake build) - Printable Version +- MYSTRAN Forum (https://www.mystran.com/forums) +-- Forum: MYSTRAN (https://www.mystran.com/forums/forumdisplay.php?fid=4) +--- Forum: MYSTRAN (https://www.mystran.com/forums/forumdisplay.php?fid=5) +--- Thread: BANDIT crash on Windows (MSYS+CMake build) (/showthread.php?tid=48) Pages:
1
2
|
BANDIT crash on Windows (MSYS+CMake build) - borges - 08-28-2020 I think it's a good idea to sum up all the information regarding the whole BANDIT/CMake/Windows situationin a thread over here. Here's a quick run-down of what happened:
Some extra points that came up during discussion and are very much worth mentioning:
RE: BANDIT crash on Windows (MSYS+CMake build) - Admin - 08-28-2020 Thanks very much for the detailed information. I am in agreement with this approach. Just to clarify, the goal is to "remove" BANDIT so that we can get a clean builds across the board (with different approaches). Adding BANDIT back in will then be a separate work item. However, if we can direct resources towards adding PaStiX (which we need to do anyway), we will get a better bang for the buck. MYSTRAN very much needs a sparse solver and I think that should be our top priority. RE: BANDIT crash on Windows (MSYS+CMake build) - drbillc - 08-28-2020 With all write statements commented out in BANDIT, no bdf SEQGP entries will be generated and therefore no grid re-sequencing will occur. Maybe a more acceptable option would be just to remove BANDIT from MYSTRAN but everyone must realize that, without grid re-sequencing, problem size can be severely limited. However, this may make it obvious that the addition of a sparse solver, where BANDIT won't be needed anymore, is imperative. BTW, NASTRAN-95 uses a modified version of the original BANDIT code (modified to fit the NASTRAN code style and I/O) Let me know if the rest of you want to remove BANDIT and I will take care of it. I had thought the only issue was with the file open status=replace but it appears it is more than that when we consider OS's other than Windows RE: BANDIT crash on Windows (MSYS+CMake build) - borges - 08-28-2020 (08-28-2020, 08:24 PM)drbillc Wrote: With all write statements commented out in BANDIT, no bdf SEQGP entries will be generated and therefore no grid re-sequencing will occur. Maybe a more acceptable option would be just to remove BANDIT from MYSTRAN but everyone must realize that, without grid re-sequencing, problem size can be severely limited. However, this may make it obvious that the addition of a sparse solver, where BANDIT won't be needed anymore, is imperative. I fully agree that adding a sparse solver is high priority. However, just to clarify, I didn't comment out all the write statements, only some "offending ones". They all seem to be diagnostics messages written to IOU6 (bandit.out) and IOU8 (bandit.f08). I ran some tests to see what effect their absence would have on both OSes. On Linux, the SEQGP cards are indeed still generated, as per the output BANDIT files. MYSTRAN proceeds normally. On Windows, BANDIT sometimes fails to run for another reason (code 4?), but does not cause a crash. MYSTRAN reports the BANDIT failure and proceeds otherwise normally. RE: BANDIT crash on Windows (MSYS+CMake build) - drbillc - 08-28-2020 Borges, if you want to keep BANDIT with the offending write's commented out that would be fine with me. Until we get a sparse solver problem size will be quite limited anyway so either option works RE: BANDIT crash on Windows (MSYS+CMake build) - borges - 08-28-2020 (08-28-2020, 10:01 PM)drbillc Wrote: Borges, if you want to keep BANDIT with the offending write's commented out that would be fine with me. Until we get a sparse solver problem size will be quite limited anyway so either option works That's just the quickest way I found to get the CMake build working on both OSes. A straightforward buildspec is essential should others -- myself included -- want to contribute in the future. Now that a consistent cross-platform buildspec is out of the way, I've been focusing on getting familiar with Fortran and the other tasks at hand. It's a long road, but I want to help. RE: BANDIT crash on Windows (MSYS+CMake build) - drbillc - 08-28-2020 OK, lets go with the BANDIT you have with the offending write's commented out. Can you post that file? I'm new to GitHub and not quite sure of how to do that and thanks for your help. We need folks like you to keep this thing alive RE: BANDIT crash on Windows (MSYS+CMake build) - borges - 08-28-2020 (08-28-2020, 10:31 PM)drbillc Wrote: OK, lets go with the BANDIT you have with the offending write's commented out. Can you post that file? I'm new to GitHub and not quite sure of how to do that It's all live on my fork, for which I have a pull request into your master branch. =) P.S.: The edit diff for BANDIT_MODULE.f looks huge because my editor (Atom) removed loads of trailing whitespace. That should have no practical effect other than... huge diffs. RE: BANDIT crash on Windows (MSYS+CMake build) - drbillc - 08-28-2020 I'm new to this process. Tell me how I should accept the change. Do I just click on "Merge Pull Request". RE: BANDIT crash on Windows (MSYS+CMake build) - borges - 08-28-2020 (08-28-2020, 11:13 PM)drbillc Wrote: I'm new to this process. Tell me how I should accept the change. Do I just click on "Merge Pull Request". That'd merge ("copy") my fork's changes into your repository. Have you talked to Brian about this? I was coordinating an eventual pull request with him before. He had some (valid) objections to my changes to the README. Nothing on GitHub is irreversible, though, so no need to worry in case something breaks. |