And add their bin folders into Windows PATH. Then you can start to build SuperLU.
1. Download from https://github.com/xiaoyeli/superlu On that page, click Code, select Download ZIP 2. Unzip it into D:\MYSTRAN\superlu-master folder 3. Copy w.bat (see attached) into D:\MYSTRAN\superlu-master (Rename the attached w.txt as w.bat) 4. On lower left corner of Windows desktop, inside the search area, type CMD, then press Enter key to start cmd.exe - the windows terminal. 5. Change to D:\MYSTRAN\superlu-master folder 6. Type w in the windows terminal command line, then press Enter key to run w.bat It will find the tools needed to build SuperLU. It will generate a D:\MYSTRAN\superlu-master\Build_win10 folder and changed into that folder.
7. Type make, then press Enter key to build SuperLU.
! First, factorize the matrix. The factors are stored in *factors* handle.
iopt = 1
call c_fortran_dgssv( iopt, n, nnz, nrhs, values, rowind, colptr,
$ b, ldb, factors, info )
if (info .eq. 0) then
write (*,*) 'Factorization succeeded'
else
write(*,*) 'INFO from factorization = ', info
endif
! Second, solve the system using the existing factors.
iopt = 2
call c_fortran_dgssv( iopt, n, nnz, nrhs, values, rowind, colptr,
$ b, ldb, factors, info )
if (info .eq. 0) then
write (*,*) 'Solve succeeded'
write (*,*) (b(i), i=1, 10)
else
write(*,*) 'INFO from triangular solve = ', info
endif
! Last, free the storage allocated inside SuperLU
iopt = 3
call c_fortran_dgssv( iopt, n, nnz, nrhs, values, rowind, colptr,
$ b, ldb, factors, info )
I've added support for Mystran (the BDF and for the GUI). You can flag the deck as a Mystran file by putting the following on the first line of your BDF:
$ pyNastran: version=mystran
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.
