Re: [Plplot-general] Fortran input unit conflicts

[Spong, D. A. <sp...@or...>]

Hi Alan and Arjen,

I’ve now done some further testing on my I/O problem and am happy to report that it does not seem to be Plplot’s problem, but rather a bug in Intel’s newest ifort compiler. In answer to your earlier questions, I do use a proper open statement in my Fortran code and I had tried the INQUIRE statement, but was finding every unit number was tied up whenever I tried to link with Plplot. I’m running Mac OS10.10.4 and Intel ifort 16.0.0.

What I recalled was that after installing Plplot 5.11.0, I had successfully compiled and run a Fortran/Plplot code that both opened and read a file and made a plot. However, not long after this I had agreed to be a tester for Intel’s newest Parallel Studio 2016 Beta program. I just made the test of reverting back to the previous ifort version 15.0.2 and the code I was having trouble with works fine; when I switch to ifort version 16.0.0 it fails in the way I described. So I will contact Intel and see what they have to say. Using Plplot is about the only place where I mix C and Fortran code, so there must be some bug in their new compiler related to this. Other Fortran-only codes I’ve tested with their new compiler worked okay.

- Thanks, and sorry for the false alarm,
   Don


On Jul 15, 2015, at 3:54 AM, Arjen Markus <arj...@de...<mailto:arj...@de...>> wrote:

Hi Don,

The problem you report is rather curious – Alan’s analysis of the situation seems quite right, but that does not mean we understand what is going on. So in addition to Alan’s suggestions:


-        Can you capture the problem in a small sample program?

-        Can you tell us what OS and what compiler you are using?

-        If such a sample program is not feasible, can you use the INQUIRE statement to find out what file logical unit 15 is connected to and with what FORMAT? It would seem that if your combination of C and Fortran compilers is usurping the unit numbers, then this information ought to be available to via Fortran.


I have never encountered this situation before, and the reason that one should not mix C and Fortran I/O to the same file is that the two use their own buffering systems, making it unpredictable how notably the output will be written. That is the aspect I understand – the usurping of units is something entirely new. Nothing in the Fortran bindings for PLplot is doing that.

Regards,

Arjen

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, July 15, 2015 12:57 AM
> To: Spong, Donald A.
> Cc: plp...@li...<mailto:plp...@li...>
> Subject: Re: [Plplot-general] Fortran input unit conflicts
>
> Hi Don:
>
> To add to what I said before, everything I have quickly skimmed on this subject
> recommends all i/o be done at the C level or at the Fortran level, but not both (except
> for stdin, stdout, and stderr which typically are OK to use commonly for both C and
> Fortran).
>
> Of course, that mixture of C and Fortran level i/o is exactly what you need in this
> case since our core C library _must_ do i/o, and you want to do that as well at the
> Fortran level for your own needs.
>
> However, my feeling is that recommendation to not mix i/o from C and Fortran levels
> is just a cop-out so those references don't have to deal with that subject.
>
> It is also implied that the Fortran i/o is implemented on top of the standard C way of
> doing i/o.  If that is correct, _and you are not trying to deal with the same file at both
> the C and Fortran level_, then proper opening of a Fortran file should end up as calls
> to C i/o routines, and I don't see how those calls would interfere with C i/o or vice
> versa unless an attempt is made to use the same C i/o resources, e.g., a file
> descriptor.
>
> So if you are not doing so yet, please use a proper open statement at the fortran
> level for your unit 15.  If you do that, my (perhaps naive
> view) is the C i/o level should know about all the existing i/o resources that are in
> use when it attempts to allocate more resources regardless of whether that C i/o
> level is directly used from C or indirectly used from Fortran.  But in case there is
> some sort of bug there, do you get a different result if you call the fortran open
> routine for unit 15 _before_ you make your first PLplot call versus calling that Fortran
> open routine after that first PLplot call?
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww . phys . uvic . ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation for
> stellar interiors (freeeos . sf . net); the Time Ephemerides project (timeephem . sf . net);
> PLplot scientific plotting software package (plplot . sf . net); the libLASi project
> (unifont.org/lasi<http://unifont.org/lasi>); the Loads of Linux Links project (loll . sf . net); and the Linux Brochure
> Project (lbproject . sf . net).
> __________________________
>
> Linux-powered Science
> __________________________
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that you need to
> offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> hxxps://www.gigenetcloud.com/
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...<mailto:Plp...@li...>
> hxxps://lists.sourceforge.net/lists/listinfo/plplot-general

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.