With the help of Cean Wang I was able to get the sparse solver SuperLU downloaded and compiled into 2 libraries, libsuperlu.a and libblas.a . Using these, along with the c routine: c_fortran_dgssv.o I modified MYSTRAN's LINK3 solution of the L-set displacements (from the equation KLL*UL = PL) to run using SuperLU as a sparse solver. I ran a series of test problems, for which I have known solutions, to see how SuperlU performed. The series of test problems were of a square, simply supported, thick plate under a pressure load. I ran successively larger meshes up to a maximum of 800x800 plate elements with 1,920,000 L-set degrees of freedom (DOF). SuperLU ran all of the test problems successfully up to the almost 2 million degree of freedom problem (but took an excessive amount of time for this largest DOF run). The banded solver (LAPACK) couldn't come close to running anything this large. It would have required almost 40 GB of storage for the banded KLL array LAPACK uses. LAPACK couldn't even run the smaller 500x500 mesh problem with 750,000 L-set DOF. LAPACK needed 9 GB in this case but Windows will not allocate more than 2 GB to any array
There are a number of other subroutines (approximately 10) in MYSTRAN that need to be modified to take advantage of this new sparse solver. For example, reduction of the G-set stiffness matrix, KGG, to the N-set involves eliminating the dependent DOF identified on MPC's and rigid elements. However, for the test problems mentioned above, none of these effects in the 10 additional subroutines were needed and for many problems in general the inclusion of the sparse solver that has been done for LINK3 will be sufficient. Over the next few months I will try to get the other routines reprogrammed to use SuperLU but, in the meantime, most simple statics problems will run the new sparse solver very effectively.
I will post the updated MYSTRAN, with SuperLU incorporated into LINK3, to GitHub later this week
Cean has a thread with the procedure to compile SuperLU. If anyone uses it ignore his comments on how to incorporate into MYSTRAN. Only use up to step 6 in his procedure (outlined below):
From Cean:
Download and execute the cmake msi binary from www.cmake.org/download. This will install cmake into C:\Program Files\Cmake
Download SuperLU as a zip file, unzip it to D:\MYSTRAN\Cmake
Start Windows Terminal and change to D:\MYSTRAN\SuperLU (Use FreeCommander XE program is more easy to do this.)
Configure with my w.bat script as before,
Run make to build SuperLU
then, to test SuperLU prior to incorporating into MYSTRAN:
After building SuperLU successfully, change to D:\MYSTRAN\SuperLU\FORTRAN
Run make to build the FORTRAN example.
You could look at f77_main.f to see how it is called.
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.
----------------------
SuperLU
----------------------
We previously were going to add the PaStiX sparse solver. However, we opted for the SuperLU sparse solver instead, partially due to convenience. 11.3 now contains the SuperLU sparse solver. At a later date, we may add an option to use PaStiX or another sparse solver (this would be in addition to the SuperLU option).
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.
