Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Linux Compiling
#11
That sounds great. Both Bill and I are new to GitHub, but we will try to get it all sorted out. Is there a way to test this on Windows as well? That would be very helpful since the developer for OP2 output has had an issue with CodeBlocks and a more direct process might be best. Thanks for the help, it seems you know quite about this (as well as NASTRAN-95). Based on your comments about NASTRAN-95 in the other thread, I think MYSTRAN is a great alternative.
Reply
#12
(08-13-2020, 05:54 PM)Admin Wrote: That sounds great. Both Bill and I are new to GitHub, but we will try to get it all sorted out. Is there a way to test this on Windows as well? That would be very helpful since the developer for OP2 output has had an issue with CodeBlocks and a more direct process might be best. Thanks for the help, it seems you know quite about this (as well as NASTRAN-95). Based on your comments about NASTRAN-95 in the other thread, I think MYSTRAN is a great alternative.

Regarding Windows, I think it'll be all the same. I mean, if we're compiling with gfortran, it's pretty okay to assume there's a GNU environment (e.g. make, as, ld, ar), be it a real Linux environment or a Windows environment with MinGW installed (which you'll already have downloaded in order to have gfortran in the first place); so all one would otherwise need to compile is CMake and the repo.

So, regardless of being Windows or Linux, as long as there's a GNU environment and CMake, one would simply invoke cmake then make. The process would play out just the same, save for automatically picking the "OS-specific" files as opposed to user intervention. And there's more: with a little bit of effort, I believe this could be cross-compiled as well, meaning a Linux machine could compile binaries for Windows in the future if need be.

As for testing under Windows, I'll get to that soon enough, but the outlook is good. In the end, I'll only make the pull request when I'm sure we have a reliable build spec that works seamlessly for both OSes.

And yes, MYSTRAN appears to be the most promising OSS alternative, that's why I really really want this to work.
Reply
#13
Great, when complete, can you put together a detailed process write up (it may be simple?). We can then try it on Windows at least.

FYI, for the Code::Blocks build, there are 3093 warnings (0 errors)...so quite a few. Bill decided this is acceptable (at least for now) and the test runs (DAT/BDF) are working OK. It could be something that is investigated further at a later date though.

And I think we can get everything worked out on MYSTRAN. It is a newer code base and I much more developer friendly than NASTRAN-95. I think this is the main advantage. We just need to continue to work it and add features.
Reply
#14
As promised, I set up a fork and made a pull request. I got it to reliably compile and run under both Linux and Windows!

The CMakeLists.txt -- albeit much better organized than its previous iteration -- is still kinda rough around the edges (I had zero prior experience with CMake!), but the instructions on the README are precise and, hopefully, hard to get wrong. Good start, right?

I hope it works should you give it a shot... Any thoughts?
Reply
#15
I will have a look and let Bill know as well. Its great that you got it compiling for both Windows and Linux (without Code::Blocks)! This gives developers another compiling option and opens up the Linux avenue (I am not sure sure if C::B can be used to compile MYSTRAN in Linux). In any case, we will work to get everything updated and thanks very much for your contribution.
Reply
#16
I have a version which includes BANDIT. Got the exe, but has problem to run.Talked with Bill. Need a bit fine turn of the order.

Glad you have a runable exe.

Edit:

I tried to compile with your script under windows. The exe still has problem to run. Could you solve the all-elem-test. dat case?
Reply
#17
(08-14-2020, 11:15 PM)ceanwang Wrote: I have a version which includes BANDIT. Got the exe, but has problem to run.Talked with Bill. Need a bit fine turn of the order.

Glad you have a runable exe.

Edit:

I tried to compile with your script under windows. The exe still has problem to run. Could you solve the all-elem-test. dat case?

This is most weird. I managed to run that test case under Linux with my binary, and under Windows with the publicly-released binary, but the one I compiled was no good, there's some error being raised in the output functions.

I attached all input and output data and files from the three runs (public Windows binary, CMake Windows binary, and CMake Linux binary).

Okay so... I have some points I think we should keep in mind while investigating this.

  1. GNU gfortran is a rather consistent compiler for F90/F95, so this being a gfortran bug is unlikely, but not impossible.
  2. Can we guarantee the same source code used for the public EXE is the same as git latest's? If not, this might have been introduced in the meantime.
  3. The fact the exact same source code produces different behavior should trace this error back to the OS-specific files, but none of them are tied to output formatting AFAIK, so this is a bit concerning indeed.
  4. Thanks to some random glitch in MinGW, I can't get a proper backtrace of the error, all we know is it was raised in the BANDIT_MODULE.f file, line 677 (see the output files (stdout/stderr will be of most help) for details)
  5. I do not think this has anything to do with the compilation order/process, as it would've probably caused a link-time diagnostic messag...
  6. ...neither do I think this has anything to do with my only change to the READ_CL source code, since it does not have anything to do with formatted output.
Unfortunately, it'll be really hard to pinpoint where the error's being raised and why until someone manages to get a proper backtrace on the error. I'm working on that, but I don't think I'll be able to do much more than that with my (very) limited knowledge of Fortran.


Attached Files
.zip   ALL-ELEM-TEST_Windows_CMake_EXE.zip (Size: 8.68 KB / Downloads: 0)
.zip   ALL-ELEM-TEST_WIndows_Public_EXE.zip (Size: 138.81 KB / Downloads: 0)
.zip   ALL-ELEM-TEST_Linux_CMake_binary.zip (Size: 129.39 KB / Downloads: 1)
Reply
#18
P.S.: I'm really, really confused right now. Check this out:

So, the Fortran runtime complains that we're attempting to perform a formatted write to an unformatted output.

Line 677 is a WRITE to IOU6. Well, let's see where IOU6 is OPEN'd. That'd be line 408:

Code:
OPEN(IOU6,FILE='bandit.out',FORM='FORMATTED',STATUS='replace')

This so not very nice. Why does Fortran think IOU6 is unformatted? And why only on Windows? Is this a gfortran bug?

The only other reasonable thing I can think of is stack corruption, But... surgical enough to change file descriptor info and nothing else? Unlikely.

And why only on Windows? My head hurts.
Reply
#19
(08-17-2020, 02:59 PM)borges Wrote: Line 677 

Found a solution for this. No problem now.
Reply


Forum Jump:


Users browsing this thread: 6 Guest(s)