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
<arjen.mar...@deltares.nl<mailto:arjen.mar...@deltares.nl>> 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...@beluga.phys.uvic.ca]
> Sent: Wednesday, July 15, 2015 12:57 AM
> To: Spong, Donald A.
> Cc:
> plplot-general@lists.sourceforge.net<mailto:plplot-general@lists.sourceforge.net>
> 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
> Plplot-general@lists.sourceforge.net<mailto:Plplot-general@lists.sourceforge.net>
> 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.
------------------------------------------------------------------------------
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.
https://www.gigenetcloud.com/
_______________________________________________
Plplot-general mailing list
Plplot-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-general
