This thread is in-work, but provides some basic information about to implement a sparse solver to MYSTRAN.
----------------------
MYSTRAN Information
----------------------
In the following link, there are notes for how to incorporate a sparse solver. PaStiX seems to be best option for this. More information about PaStiX will be added later.
Under Sources\Specifics, there are files for Windows and Linux system.
Here is a script to compare them. Put the script under Sources\Specifics folder and run cpSrc.bat, the difference will saved in a cpDiff.txt file.
For GET_INI_FILNAM.f90, the difference is:
Code:
InputObject
-----------
! ##################################################################################################################...
! Gets name (incl path) of the MYSTRAN.INI initialization file. This is the Linux version which uses '/' as a folder...
INIFIL(MYSTRAN_DIR_LEN+1:MYSTRAN_DIR_LEN+2) = '/'
! Gets name (incl path) of the MYSTRAN.INI initialization file. This is the Windows version which uses '\' as a fold...
INIFIL(MYSTRAN_DIR_LEN+1:MYSTRAN_DIR_LEN+2) = '\'
There should be a way to work for both OSes, '\\' ?
For GET_MYSTRAN_DIR.f90, the difference is:
Code:
InputObject
-----------
! ##################################################################################################################...
CHARACTER(FILE_NAM_MAXLEN*BYTE), INTENT(OUT) :: MYSTRAN_DIR ! Directory where program executable (and IN...
INTRINSIC :: GET_ENVIRONMENT_VARIABLE
CALL GET_ENVIRONMENT_VARIABLE ( 'MYSTRAN_directory', MYSTRAN_DIR, MYSTRAN_DIR_LEN )
! Gets the environment variable MYSTRAN_DIR that tells Windows where the MYSTRAN executable is located. The user mus...
! environment variable on their computer
CHARACTER(FILE_NAM_MAXLEN*BYTE), INTENT(OUT) :: MYSTRAN_DIR ! Directory where executable (and INI file) ...
INTRINSIC :: GETENV
CALL GETENV ( 'MYSTRAN_directory', MYSTRAN_DIR )
MYSTRAN_DIR_LEN = FILE_NAM_MAXLEN
DO I=FILE_NAM_MAXLEN,1,-1
IF (MYSTRAN_DIR(I:I) /= ' ') THEN
EXIT
ELSE
MYSTRAN_DIR_LEN = MYSTRAN_DIR_LEN - 1
CYCLE
ENDIF
ENDDO
I think GET_ENVIRONMENT_VARIABLE (Fortran 2003 and later) and GETENV (backwards compatibility with GNU Fortran 77) could use one to work for both OSes. In new code, programmers should consider the use of the GET_ENVIRONMENT_VARIABLE.
For READ_CL.f90, the difference is:
Code:
InputObject
-----------
! Begin MIT license text.
! _______________________________________________________________________________________________________
! Copyright 2019 Dr William R Case, Jr (dbcase29@gmail.com)
! Permission is hereby granted, free of charge, to any person obtaining a copy of this software and
! associated documentation files (the "Software"), to deal in the Software without restriction, including
! without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
! copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to
! the following conditions:
! The above copyright notice and this permission notice shall be included in all copies or substantial
! portions of the Software and documentation.
! THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
! OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
! FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
! AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
! LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
! OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
! THE SOFTWARE.
! _______________________________________________________________________________________________________
! End MIT license text.
! ##################################################################################################################...
All are comments. So there should be no difference for this file.
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:
In the interest of getting a consistent, faster build process (without Code::Blocks) and supporting Linux, I updated Cean's CMakeLists.txt file, enabling users to compile MYSTRAN (using gfortran) under both Linux and Windows (using MSYS).
The resulting binaries worked fine on Linux, but caused runtime errors on Windows. Those crashes originated in WRITE calls in BANDIT.
We were unable to find an explanation for the uncovered OS-dependent behavior. It's a really weird glitch in how the runtime is treating opened files.
In the interest of getting this improved build process out there, I also commented out all offending WRITE calls. After that change, the Windows binary seems to work.
That's the current state of my fork: CMake cross-platform improved build spec and silenced BANDIT.
Some extra points that came up during discussion and are very much worth mentioning:
BANDIT is comprised of legacy F77 code. This may be related to the "quirky" behavior across OSes.
Even though the test cases run on Windows after silencing BANDIT, it still reports BANDIT failed (code 4). That doesn't happen on Linux. Maybe the glitch causing this inconsistent behavior runs deeper than we previously thought.
That may explain why others were unable to reproduce this behavior in simple test programs.
Since integrating a better solver (PaStiX) is in the works and it doesn't need BANDIT, "fixing" BANDIT doesn't seem worth the effort. PaStiX should be the priority.
Still, until that's done, it's good to have an alternative build process working.
Same as the 3-TestRuns folder, create a 8-Test folder and save this msolve.bat file in it. Please remove the txt extension.
Run, it will solve all dat files in 3-TestRuns\Statics\Banded\CurrentRuns folder.
Regards,
Cean
After solving all the cases, you could compare the newly generated *.ANS to the corresponding *.ARC files under the 3-TestRuns\Statics\Banded\Archive folder using these two bat files. Also save and run in 8-test folder. Please remove the txt extension.
cpARC.bat will call compareARC.ps1 to compare the pair of files line by line. compareARC.ps1 is a Window 10 PowerShell's script. It will write the difference into the cpDiff.txt file.
The problem at the moment for me is that the ARC file treat 0 different to my ANS file. One has - sign at the front of 0. I think if the exe is generate by same compiler, there will be no problem.
I would recommend gmsh, at least for postprocessing. The MSH file formats (ASCII and binary) are very well suited for it in my experience (small, medium model sizes) and in ascii format easy to check and modify if necessary. Plotting capabilities are as good as femap and allows for nodal and elemental results. I have created the files with text processor sometimes for small models using f06 results. I think is as good as femap .neu file and easier to read and can be used with a software that is free & open source that does not need installation and runs in all platforms (macOS, windows and linux).
I attach an example so you can check by yourselves (this is an ascii file in legacy format 2) for normal modes of a small model (remove .txt extension before opening with gmsh).
What are the options for compiling on Linux Ubuntu? Is there a CMake file for linux?
The github instructions are not very enlightening:
"If compiling for Linux:
1. Rename the other 3 files in this directory to have a ".f90" extension instead of a ".tmp" extension.
2. Delete the files in the "1_Windows" directory."
