forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Inconsistent type for must_exit argument, Get_Filtered_File$

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Nov 18, 2019 2:19 pm    Post subject: Inconsistent type for must_exit argument, Get_Filtered_File$ Reply with quote

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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Nov 18, 2019 4:12 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Nov 18, 2019 4:31 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Tue Nov 19, 2019 12:42 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Tue Nov 19, 2019 2:40 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Thu Nov 21, 2019 5:37 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Fri Nov 22, 2019 3:56 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Fri Nov 22, 2019 4:31 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Fri Nov 22, 2019 5:54 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sat Nov 23, 2019 8:41 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sun Nov 24, 2019 1:59 am    Post subject: Reply with quote

Just have seen today Supermicro made EPIC Rome server which looks like regular PC box with two 64core chips. Wow.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Sun Dec 01, 2019 7:31 am    Post subject: Reply with quote

Regarding the mejej4-Eddie debate ...

Eddie's comment about:

"the additional effort just generates more precise, but not necessarily more reliable, answers."

ding-dong's an normous bell with me regarding structural calculations which is my domain.

Stress concentrations for example and FE models -

- todays 'capabilities' of FE programs (microscopic meshing) because it's so easy to do it means a lot of young engineers just plonk out numbers willy nilly and think they're getting the right answer automatically.

... and, managers believe that the results must be correct because it's a lovely looking model.

But then the problemes arrive first with computing turn-around time, then post-processing time and then, dare I say it,the answers might not be correct !

- just use a much simpler model and a factor of 3 (or 5 if the hole is not modelled) and presto, 9 times out of 10 you'll get just as good an answer.


" grasp (of) of the requisite parameters"
is also a black box that younger engineers in general are loath to spend time on , believing (not their fault, it's what they're taught at uni these days) that 'god in his wisdom' created FE which is all singing, all dancing, all the more accurate, but they are ignorant of the basic facts, like :
FE is only really good for loads analysis - so be sceptical of all stress results in a model !

Hand calculations ? nah, most of them have never done one in their lives.
They might SAY they have, but they're talking about excel, mathcad, tc .....calcs. That's a programming exercise is that, not hand calculations.

How many peple actually calculate by hand written calculation the same as that they think they've put in the hurdy-gurdy calculations ?

Not many I'll wager.

How many of the new wave young structural engineers have actually picked up Roark and done calculations by hand from it ?

Not the odd calculation in the context of a course at uni, but full blooded calculations for weeks on end, using a pencil !.

Not many I'll wager.

And of those who have ...... how many are concient of the Roark error ists ? !!!!! yes there are errors , so if you've ever programmed Roark equations (via ftn95, or excel, or whatever .... beware your calculations might be wrong from the offset !

Computers ar perfect of course, but as Eddie points out, what you get out depends on what you put in, which by definition means getting your input data right.
Computer speed is only one parameter in the efficiency of work.

Then there's something we all forget.
Many of these 'desireable' speeding ups need .... manpower and effort.

Silverfrot have a fin product, developed over many years.
We ccan't expect them always to be able to spend 'infinite' time on all problems.

Companies like Intel have 'infinite' manpower, due to their size.
As do other other purveyors of compilers.
Sure they have negative aspects, like controlling and organising that 'resource' (10 times more programmers doesn't mean something i developed 10 times faster), bu it's an advantage for sure.

Silverfrost don't hve that luxury, which is why I guess that some things are put on the back-burner.

All companis should be obliged by law to have a video-recorded log of all development processes.
Future generations would learn a lot when they realise they make the same mistakes ![/b]
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group