Re: [Plplot-general] Fortran input unit conflicts

[Arjen M. <Arj...@de...>]

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...
> 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); 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.
> https://www.gigenetcloud.com/
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://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.