Inconsistent type for must_exit argument, Get_Filtered_File$

The interface declared in ...\source64\clrwin.f95 for get_filtered_file$ shows the last argument as integer(C_INT). On the other hand, the example file FILTER.F95 in ...\Documents\FTN95 Examples\clearwin declares that argument as LOGICAL.

I suspect that the example files work fine with FTN95 since the interfaces are built in. However, the correct interface will be needed when using Clearwin64 with a different (e.g., Gfortran, Intel) compiler.

Please confirm if this is so, and you may consider updating the example source files.

I think that you are right. Presumably gFortran uses strong type checking in this context whilst FTN95 does not. As far as FTN95 is concerned it doesn't matter whether the type is LOGICAL or INTEGER.

I am not sure what action to take other than to add a comment to the sample code.

Paul,

The bit pattern used in Fortran for LOGICAL values can vary from compiler to compiler, so the INTEGER(C_INT) way is probably required if the Fortran-xx compiler differs from FTN95 in that regard. A comment with that information could be inserted into each example source file that contain calls to CLRWIN/MSWIN routine with one or more LOGICAL arguments.

We got a fair sized engineering application working with Intel Fortran and Clearwin+, and this issue came up while developing the GUI.

Thanks.

mecej4 Please share some day your experience on how you linked CWP and other Fortran. For example i can write

abc=10 WRITE(,) 'Variable =', abc end

classical way. But with Clearwin i can do that this way

abc=10 i=winio@('Varaible=%rf', abc) end

These two examples were complete codes, nothing else needed. How you can do that with other Fortran compilers?

Dan,

The recipe is given at https://www.silverfrost.com/ftn95-help/clearwinp/util/64bit.aspx .

I am a novice w.r.t. Clearwin, GUIs and graphical output. At my request, a collaborator provided me a working version of the source code stripped of GUI and graphics calls. Many portions of the original source code had lots of spaghetti F77 code, some of which had been recently cleaned up by my collaborator. Then, I worked on the computational parts of the code, with standard character and file I/O, to clean up the code, remove a number of bugs and to insert more robust and efficient algorithms (for solving PDEs related to some thermo-physical problems). The collaborator then reinstated the GUI+Graphics calls and worked with the code to make it run with FTN95. In the final step, I simply made the minimum modifications necessary to get the code to compile, build and run with FTN95 and the other compilers.

With a little planning ahead, the development of source code that will work with a foreign compiler can be almost as simple as with FTN95-64. With a few pre-processor directives added to the source code, the same codebase with Clearwin+ calls can be compiled with FTN95, Gfortran, Intel and NAG.

It is best to do the debugging with FTN95 alone. There is little support for debugging code with Clearwin+ calls with the other compilers' debuggers.

You will have to overcome a number of difficulties: bugs in the other compiler, bugs in the code generated by FTN95, especially with /OPT, and bugs in SDBG64, not to mention bugs in your own code. If you do not use the correct interfaces to Clearwin+, as illustrated by this post, diagnosing and fixing the interfaces can be daunting. You will have to provide equivalent code that the other compiler can compile for non-standard Fortran extensions that are allowed in FTN95.

But then, Dan, this is all breakfast fare for you, so enjoy the protein-rich repast. An EXE compiled with the other compiler may appear to be exactly the same as the one compiled with FTN95, but running 2-X to 3-X faster, with avenues open to you for using libraries such as IMSL, NAG-FL, etc. In fact, the EXEs produce screens that gave us no indication of which compiler or which algorithm variant had been used, so we had to insert some flags in the top-line graphical display to identify the compiler and the variant of the algorithm.

It's always been the case that INTEGER and LOGICAL have been somewhat interchangeable in FTN95, as I pointed out a good number of years ago in respect to USE_RGB_COLOURS@ - long before it became the default.

As for running 2x to 3x faster, I think it is worth pointing out that the comment can only apply to the non-ClearWin+ parts of the code, unless one can find a way of speeding up the underlying Windows interface, which I suspect that would only happen if the workers at MS HQ spent less time inhaling smouldering herbal mixture!

Whether or not that is worth the effort is moot. Not all speed gains are worth the effort. For example, if one spends an hour in data input, and the run time is 20 seconds, there is not much point in reducing that to 10 seconds or so as the hour is committed by the speed of human brain, eyes and fingers and not by the computer. That said, there are times when the speed-up is useful - perhaps - but almost never when one is programming for oneself.

Unless one values one's time as worthless.

Eddie

Eddie,

I gave you the context: obtaining the solution of a partial differential equation. Even for the solution of a 1-D transient P.D.E., the solution time is usually at least a few minutes. In 3-D, and with more than one dependent variable (pressure, velocities, temperature, concentration), and time-dependent boundary conditions, a single run can range from a few minutes to several hours.

There were some runs of the original application that exceeded 24 hours. Often, after several hours of running, the program would fail, following which the input data had to be tweaked to improve the chances of success in subsequent runs. These difficulties were one reason why I was approached.

DanRRight has often written about such predicaments in his own work.

It had never occurred to me to ask if I am 'programming for myself'. If you can avoid working on programs that run for long times, have no use for other compilers and tools, or all your computational work can be performed using a 12-inch slide rule, good for you!

I am grateful that I am not restricted to working on only simple problems.

Thank you for your observations.

As I said, there are occasions when speeding up the runtime by a factor of two or three is a pointless exercise. Take for example an eight hour run time. Assuming a normal working day, and software that doesn’t crash, this is going to be run overnight. If you speed it up by a factor of two or three, you are still probably going to run it overnight. But no benefit is gained. That was the context I meant. A 24 hour runtime is usefully compressed to overnight, I will concede.

If you want to run that overnight problem during the day, then the solution is a second computer, dedicated only to that, and if you want multiple runs at the same time, then more computers. Another answer is faster computers, but that sometimes means waiting a year or two – or more – for them to come onto the market.

There is benefit in making things a lot faster, for example, if you can get it to run in your lunch break instead of overnight, then excellent – you get the results on your return. The worst run times are those that seduce you into watching the progress bar, or which are too short to do something else useful in.

I am afraid that I have passed beyond the era of overnight and longer runs, as you guessed correctly.

Alas, I have discovered that in the ground, one rarely has a good enough grasp of the requisite parameters or of the stratigraphy to justify more than a certain degree of sophistication in one’s models, and the additional effort just generates more precise, but not necessarily more reliable, answers.

I write this advisedly, because in my eighth decade, I often work on fixing problems created by the use of ever more sophisticated analyses based largely on guessed parameters and oversimplified stratigraphy, conditioned by design codes that are poorly understood and sometimes even wrong.

Eddie

PS. I checked my slide rule. The scales are 10'. There are problems where the slide rule gives you at least as good an answer as a PC. I reckon it must be quite a lot of decades since I used it in earnest.

E

If Silverfrost optimized run time performance like all other compilers have done almost instantly ages ago and added MPI, the FTN95/Clearwin had a chance to be used with supercomputers. With their Clrearwin, perfect speed, graphics, may be also automatic parallelization, Silverfrost would be industry standard with all their @ extensions or whatever f@rt they would produce to the world in the future. There also would be no need in trickery like Clearwin+IVF Fortran or Clearwin+Gfortran. And all that adoption to other compilers would become a wasted time.

Look at the recent AMD 64core EPIC chips. Computer with just two such processors would be enough for me for most of tasks being equivalent to 1000+ core older supercomputer on some tasks which do not scale well with the number of cores (like with our PIC codes which mostly do not) Increasing core count from 100 to 1000 for example improved speed only 2 times. But to get CPU time on 1000core computer requires 5 days waiting in the queue. So just having 128 cores would be 2.5 times more efficient in terms or real work done, costing almost nothing, and consuming less than 1 kW of power. Support Windows Server OS is also not harder than with regular PC or cell phone. FTN95 has to be ready for personal supercomputing revolution.

Just have seen today Supermicro made EPIC Rome server which looks like regular PC box with two 64core chips. Wow.