Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 19 11:19
    szaghi commented #7
  • Sep 19 11:08

    szaghi on master

    Fix parsing bug issue#7 The me… update travis config Merge branch 'release/0.1.0' (compare)

  • Sep 19 11:06

    szaghi on fix-parsing-bug-issue#7

    (compare)

  • Sep 19 07:54

    szaghi on fix-parsing-bug-issue#7

    (compare)

  • Sep 19 07:52
    szaghi commented #7
  • Sep 19 07:51
    szaghi labeled #7
  • Sep 19 07:51
    szaghi assigned #7
  • Sep 18 19:07
    NicSAE opened #7
  • Aug 29 08:09
    ito436 opened #6
  • Jun 19 11:43

    szaghi on master

    Merge tag 'v0.0.7' into develop… Merge branch 'master' into deve… Merge tag 'v0.0.8' into develop… and 3 more (compare)

  • May 28 14:57

    szaghi on master

    update submodules (compare)

  • May 28 14:06

    szaghi on master

    update submodules (compare)

  • May 28 14:04

    szaghi on master

    update submodules (compare)

  • May 28 13:34

    szaghi on master

    update submodules (compare)

  • May 28 12:36

    szaghi on master

    update submodules Add missing submodule Add miss… (compare)

  • Oct 25 2018 23:58

    giacombum on ror

    fix errors with ROR active; res… uncomment debug options for Int… (compare)

  • Oct 15 2018 06:21

    giacombum on ror

    remove unnnecessary variable (compare)

  • Oct 15 2018 05:56

    giacombum on ror

    Amend standard errors (compare)

  • Oct 12 2018 17:28

    giacombum on ror

    Both tests compiling (compare)

  • Jun 28 2018 14:08

    giacombum on ror

    add new rules for cleaning add ROR strategy (compare)

Stefano Zaghi
@szaghi
:tada: : a small progress for gfortran, but a big progress for poor Fortran men like Chris and me :smile:
Milan Curcic
@milancurcic
@szaghi I suggest we stop using words "poor" and "Fortran" in the same sentence, it only perpetuates the false stigma that this language carries.
Stefano Zaghi
@szaghi
@milancurcic Hi Milan, sorry for my bad humor, I promise I'll be more careful in the future, with hope without stigma :smile:
Milan Curcic
@milancurcic
@szaghi Thanks Stefano! I am convinced of your genuinely great intentions :)
Neil Carlson
@nncarlson
I've been loosely following the recent discussion with great empathy. I want to remind people that Fortran /= gfortran. There are better compilers out there than gfortran. It would be ideal to have a top-notch free Fortran compiler, but that's not where we are right now. I understand that everyone's situation and priorities are different, but it might be worthwhile considering using a different compiler.
Stefano Zaghi
@szaghi

@nncarlson Dear Neil, thank you for sharing your thoughts, it is appreciated.

If the idea of Fortran == gfortran was conveyed by me, my bad, it is not my thought neither I want to convey it. In my view a good program must be tested with as much as possible different compilers to obtain cross-verification: compilers are programs as others thus they could (and are) be bugged as others. To me Fortran == iso-standard-xx.

My current feeling is, however, sad. Due to the sempiterna lack of funds in my research institute I have to strongly rely on free compilers; the access to commercial compilers is possible only when we buy core-hours at HPC facilities or when we obtain a grant at them (1 or 2 times for year, in mean). So, my view is strictly related to Intel and GNU: both have serious bugs about OOP, thus this blocks me.

I tested PGI, but it has too much limited support to F03/08 and no support at all to CAF; it was even very inefficient (in some scenario) if compared with Intel and GNU.

I used IBM XLF when I had a grant on PowerPC cluster, it is a great compiler, but it is not an option for x86 GNU/Linux.

Others said great things about Cray, but I did not never accessed to a CRAY cluster.

Finally there is NAG that seems great, but it is too expensive for me and Cineca (the HPC where I often obtain grants) does not provide it.

All said means, *I agree with you, Fortran /= gfortran, but, for someone like me Fortran ~= gfortran + ifort is a good approximation :cry:

Cheers

Neil Carlson
@nncarlson
@szaghi, I'm very curious to hear what your OOP issues with the Intel compiler are (perhaps off-line). That is our go-to production compiler now. It had many problems in the past (I reported many) but has greatly improved in the current version. I'm not aware of any current issues that effect me (well, perhaps one ...), but it sounds like it still has some significant problems that I should be looking to avoid.
Stefano Zaghi
@szaghi
@nncarlson Hi Neil, currently these are the issues frustrating me with Intel: CAF issue and ADT issue (this other is similar or the same issue of the other ADT issue.). I am in the 2018 beta testing and these bugs seem to be not fixed.
Jacob Williams
@jacobwilliams
Neil Carlson
@nncarlson
@jacobwilliams Actually the trick of boxing the polymorphic pointer also allows you to preserve the metadata associated with the polymorphic variable. An example:
Neil Carlson
@nncarlson
program main

  use iso_c_binding

  type box
    class(*), pointer :: p => null()
  end type
  type(box), target  :: pbox
  type(box), pointer :: qbox
  type(c_ptr) :: cp

  allocate(pbox%p, source=1)
  cp = c_loc(pbox)
  call c_f_pointer(cp, qbox)

  select type (q => qbox%p)
  type is (integer)
    print *, 'got integer', q
  class default
    print *, 'lost dynamic type'
  end select

end program
Jacob Williams
@jacobwilliams
Thanks @nncarlson ! I'm still not sure what is "legal" and what isn't with C_LOC but I like this approach (at least it works on both ifort and gfortran).
Neil Carlson
@nncarlson
It also works for NAG. Using C_LOC on a polymorphic variable is an error with NAG, and I too am not sure what is "legal". I got mixed signals from FortranFan and Steve Lionel (your Intel forum link).
Stefano Zaghi
@szaghi
@jacobwilliams @nncarlson Interop-C is still a mystery for me... can I ask some details about when/where the box wrapper plus c_loc turn to be useful? Cheer
Jacob Williams
@jacobwilliams
@szaghi I'm doing some experiments using it as a way to call object-oriented fortran code from Python. I'll try to post about it soon.
Neil Carlson
@nncarlson
My use case (https://github.com/nncarlson/yajl-fort/blob/master/src/yajl_fort.F90) involved a C library that needed call back functions, which I implemented in Fortran. One of the arguments to a call-back was a user-supplied void pointer to "context data" that the call-back needed. It's a pretty standard approach in the C world. My ideal call-back was a type bound procedure of a polymorphic type with data components of the type providing the necessary context data. To get this to work with the C library, I passed the c_loc of a box wrapper around the polymorphic type pointer as the "context data". The function, whose pointer I passed as the call-back, turned this pointer back to a box around the polymorphic type pointer, and then invoked the type bound procedure that was the actual call-back.
Not sure if any of that made sense -- perhaps it's better explained with an example.
Stefano Zaghi
@szaghi
@jacobwilliams Jacob, your use case is very interesting for me, I am now using ctypes in Python but I am not still able to exploit an OOD Fortran class with it, only non OOD procedures. If you will go with this, please share your result :smile:
@nncarlson Thank you very much for your clarification, call back world is still far from way, but I am looking to your code to learn it. Thank you again.
Jacob Williams
@jacobwilliams
@szaghi jacobwilliams/Fortran-Astrodynamics-Toolkit@25a0119 is my example. I just pass a C pointer to my class back to Python, which it then can pass back into the Fortran routines where the class procedures can be called. @nncarlson I think this is similar to what you are talking about. Comments and suggestions are welcome.
Stefano Zaghi
@szaghi
@jacobwilliams @nncarlson Jacob, thank you very much for your help and insight, they are very appreciated. Neil, thank you too for sharing your work, it is of great inspiration.
Izaak "Zaak" Beekman
@zbeekman

Hi @/all, Just wanted to let you know that you can now try OpenCoarrays in the cloud via Binder. It is implemented as a kernel for Jupyter over at https://github.com/sourceryinstitute/jupyter-CAF-kernel. You can launch the binder (which also has python, Julia, and R kernels installed) using this button: Binder.

Navigate to the index.ipynb file to run a demo. Or create a new notebook using the Coarray Fortran kernel and run your own experimental code, after seeing a few tutorial details in the index.ipynb file. If you just want to skip straight to that file use this link: https://bit.ly/TryCoarrays. To get to the full on binder instance, same as the button, go to https://bit.ly/CAF-Binder

Jacob Williams
@jacobwilliams
That is amazing! Great work!
Stefano Zaghi
@szaghi
Wonderful! Great Work!
Izaak "Zaak" Beekman
@zbeekman
Also, I just want to add I installed a kernel multiplexing kernel: allthekernels. If you use that as the main notebook kernel, then you specify the kernel for each cell using >kernel-name at the top of the cell. So you could create a notebook with python, fortran, julia, r etc. cells. Perhaps this could be useful for computing some data in one language (Fortran) and then plotting it and/or post processing it in another language (python or R)
Stefano Zaghi
@szaghi

@jeffhammond

Dear Jeff,
I read this comment . It is very interesting for me, I would like to add some Autotools capabilities in FoBiS. I know about your long experience in the field whereas my knowledge of Autotools is near zero. Can you point me to some good references about the right way to identify compilers and their features? For example, I am now trying to implement in FoBiS a simple feature that should check is a compiler support the iso_10646 character kind; my idea is to that FoBiS create on the fly a simple test, invoke selected_char_kind print the result and capture it in order to understand if the compiler support it. Is this the right way (similar to the autotools one)?

Thank you in advance.

My best regards.

Jeff Hammond
@jeffhammond
@szaghi I favor the autotools style of attempting to compile code and making decisions based upon that. Autotools is often too fine-grain for most applications. if an app requires features A B C D, then write a simple source that uses all of them. if that sources compiles, use the compiler. if not, throw and error. while i use autotools for a lot of system software, in most cases, i would be fine to just test if the compiler supports C99 and POSIX, because that is what i need.
a lot of what buildsystems do is punish developers for supporting terrible platforms. i mean, if your computer doesn't have a C99 compiler, maybe you should just throw it in the trash, no? Microsoft refuses to support modern C in MSVC, and their users should revolt rather than work around this nonsense. Intel and Clang support C99 on Windows. anyways, i have strong feelings about crappy programming environments. they are a waste of everyone's time and should be ignored. i recently tried out Flang based on PGI. it's 2017 and they don't support basic features of Fortran 2008. no one who cares about modern Fortran should support this compiler.
Jeff Hammond
@jeffhammond
of course, i am biased because i work for Intel and Intel compilers are pretty good about the latest standards (and where they are not, i have filed bug reports and communicated directly with the team about the necessity of fixing the issues ASAP), and x86 has great support for GCC and Clang, but when i was supporting IBM Blue Gene and the IBM C++ compiler sucked, i advocated vigorously for Clang. https://www.ibm.com/developerworks/community/blogs/fe313521-2e95-46f2-817d-44a4f27eba32/entry/ibm_xl_compilers_for_little_endian_coming?lang=en may or may not be related ;-)
Stefano Zaghi
@szaghi
@jeffhammond Dear Jeff, thank you for your insight, I am going along your suggested approach: minimal tests (to be compiled/ran/checked on the fly) to verify if compiler support that feature. I agree with your other ideas, but I am less sharp: flang is currently inadequate for my modern Fortran approach, but I would like to support them if they are aimed to improve the compiler into a FOSS framework :smile:
My best regards
Jeff Hammond
@jeffhammond
@szaghi Indeed, I am a huge fan of LLVM and have long wished for a quality Fortran front-end for it. I have mixed feelings about PGI's front-end being the basis for that, but it's certainly better than what we had before. This community can help them understand the need for Fortran 2008+ support. Hopefully folks will also encourage them to support OpenMP 4.5 as well.
Stefano Zaghi
@szaghi
@jeffhammond :+1:
Stefano Zaghi
@szaghi

Dear @/all

I have just realized that it is possible to use gfortran 7.1.0 on Travis CI by simply selecting dist: trusty as your container (it will use the container based on ubuntu 14.xy rather than 12.xy).

My best regards.

P.S. the following is extracted from one of my .travis.yml configuration files

language: generic

sudo: false
dist: trusty

cache:
  apt: true
  pip: true
  directories:
    - $HOME/.cache/pip
    - $HOME/.local

addons:
  apt:
    sources:
      - ubuntu-toolchain-r-test
    packages:
      - gfortran-7
      - binutils 
...
install:
  - |
    if [[ ! -d "$HOME/.local/bin" ]]; then
      mkdir "$HOME/.local/bin"
    fi
  - export PATH="$HOME/.local/bin:$PATH"
  - export FC=/usr/bin/gfortran-7
  - ln -fs /usr/bin/gfortran-7 "$HOME/.local/bin/gfortran" && gfortran --version
  - ls -l /usr/bin/gfortran-7
  - ln -fs /usr/bin/gcov-7 "$HOME/.local/bin/gcov" && gcov --version
...
victorsndvg
@victorsndvg
:+1: Thanks @szaghi
Jacob Williams
@jacobwilliams
@/all If anyone is interested, I just set up a git repo here as a potential place to collaborate on writing feature proposals to submit to WG5 for the next Fortran standard. I think it's very clear from this thread that Usenet is not the future of language design discussions. :) Perhaps getting something started at the grass roots level using modern tools is the way to get the Fortran user community engaged in the process.
Stefano Zaghi
@szaghi
@jacobwilliams You are my hero! I am off due to very important public contest for a stable position, but soon I'll come back. Great initiative!
Rand Huso
@rchuso
Good Morning everyone. First time here, and it's because I have a Fortran+Polymorphism+MPI question. I'm getting unexpected results transferring an object over MPI. The object I'm sending EXTENDS an ABSTRACT object, and I'm using a CLASS pointer to the base object in the MPI_Send and Receive. Data from the base object is transferred, but not from the extended object, unless I'm using gfortran-7 and OpenMPI 2.1.1 built with gfortran-7 and gcc-7 - where data from the extended object is transferred, but not the data in the base class (which I find very strange). I've tried this using the Intel MPI (Version 2017 Update 1 Build 20161016 (id: 16418)) with ifort version 17.0.1 20161005 and gfortran-7 with a couple builds of OpenMPI. Any takers? I've got a 136 line Fortran program to demonstrate the problem. I'd like to know if I'm doing something wrong, or if I'm just expecting too much from the compiler and library implementers?
Stefano Zaghi
@szaghi
Dear Rand
Stefano Zaghi
@szaghi
Welcome here. Others will give you more insight, but from my experience your living dangerously ... This sounds a very cutting-edge MPI application. In my MPI code I usually send/receive base types, I am not so confident with current implementations. Recently I switched to CAF and with coarrays it seems more safe and natural communicate OO data. Anyhow, please share your test, I'll read it with interest. My best regards.
Rand Huso
@rchuso
Hello Stefano. "living dangerously" - I like that. With my C work processing seismic survey data (sizes up to PB, and running on the largest privately owned supercomputers in the world - like Total.com), I'm currently the fastest in the industry (if I understand what our customers are saying - my applications are 3 to 5 times faster than those of CGG and others - see the GLOBE Claritas web site for some details - part of GNS Science). I'm able to do this because of how I can abstract some of the complexity of MPI for the applications I wrote (like 3D Kirchhoff time migration - seismic tomography), and I'm trying to do the same thing with Fortran. I just want to be able to send and receive objects that have a base class. What really surprises me is the different behaviour I'm seeing with MPICH and OpenMPI using the gfortran 7.1.0 vs earlier versions. I'm in the process of changing my test routine to help me track down the progress, and will include it here when ready. Thanks.
Rand Huso
@rchuso

I got it working.

Well, it turns out the code is too large to enter here. It's at 144 lines, and successfully runs on OpenMPI 2.1 with gfortran 7.1. Is there a way to include it here for others to see?

Stefano Zaghi
@szaghi
@rchuso Hi Rand, you can create a public repo on github for free, or you can create a gist that is more suited for a simple example. Alternatively, you can send me the example and I'll create a gist/githubrepo for you. I also like to be as much as abstract as possible, but MPI implementations are often not up-to-date with Fortran OOP. Currently, I have find a serious regression with GCC 7.1 that obligates me to revert back to GCC 6.3 (the regression is not related to MPI, but it could affect also MPI implementations built with GCC 7.1). My best regards.
Izaak "Zaak" Beekman
@zbeekman
@rchuso I'd love to see what you came up with in a gist. Also, I'm curious if Coarray Fortran can suite your needs or if you are relying and certain low level MPI calls. Coarray Fortran can let you leverage one sided comms without the hassle and complexity of all the low level MPI calls. Intel has a decent (at least F2008 compliant) implementation, and GFortran w/ OpenCoarrays supports some Fortran 2015 features like events in addition to all (I think*) F2008 features.
@jeffhammond can weigh in with more details RE: ifort support for Coarrays. @rouson has a better handle on exactly which set of features are currently supported by GFortran + OpenCoarrays.
Jeff Hammond
@jeffhammond
Intel Fortran supports Fortran 2008, including coarrays. It does not support Fortran 2015 coarray features. What I know about coarrays in Intel Fortran is based upon the coarray programs in https://github.com/ParRes/Kernels/tree/master/FORTRAN. I have worked with the Intel Fortran team to improve performance in coarray programs by improving their use of MPI-3 RMA, which is the best available portable conduit for coarrays.
Rand Huso
@rchuso
@zbeekman I'm trying to get my entire mpi abstraction layer working in Fortran and C++. I've done this in Python and in C some years ago, and before the NeSI conference next year I should have all four languages implemented for my presentation. Wanted it for this year, but didn't make it. Coarray doesn't meet my needs at all - entirely the wrong direction. If I have the time this weekend I'll post my test code somewhere and give the URI here.
Izaak "Zaak" Beekman
@zbeekman
@rchuso fair, tough to use portably with other languages
@jeffhammond yes, OpenCoarrays uses MPI-3 RMA, too
Izaak "Zaak" Beekman
@zbeekman
@/all I am excited to announce the release of OpenCoarrays 1.9.1 which includes many important bug fixes.

Github Releases (by Asset) Build Status license Twitter URL

Bug fixes

  • sourceryinstitute/OpenCoarrays#325 install.sh will help user download and install Xcode command line tools (CLT) on Mac OS which is needed to compile code on Macs if it is missing or excessively outdated
  • sourceryinstitute/OpenCoarrays#378 mpirun changed to mpiexec and mpif90 changed to mpifort, consistent with MPI standard recommendations
  • sourceryinstitute/OpenCoarrays#398 fix some erroneous internal library calls when exceptions are encountered
  • sourceryinstitute/OpenCoarrays#399 fix allocation of allocatable components of coarray derived types
  • sourceryinstitute/OpenCoarrays#402 increase portability of install script install.sh by removing dependency on tree command
  • sourceryinstitute/OpenCoarrays#404 fix issue where install.sh was ignoring user specified -m/--with-cmake CMake location
  • sourceryinstitute/OpenCoarrays#406 use secure https/encrypted sources for fetching and installing prerequisites to help mitigate the possibility of a man-in-the-middle (MITM) attack
  • sourceryinstitute/OpenCoarrays#408 switch to downloading the gzipped GCC archive rather than the bz2 because gzip is more common/portable and because bz2 compressed GCC archives seem to have disappeared for some recent releases on GCC mirrors
  • sourceryinstitute/OpenCoarrays#411 fix bug causing event_post to hang when going over the network (multiple nodes)
  • sourceryinstitute/OpenCoarrays#422 clarify runtime error messages for partially or un-implemented
  • Corrected logic to control under which circumstances certain tests are run that may only work correctly under GFortran 6 or GFortran 7

Enhancements

  • sourceryinstitute/OpenCoarrays#410 add option --disable-bootstrap to install.sh to help speed builds of GCC when bootstrapping is not required because a recent GCC is performing the build
  • sourceryinstitute/OpenCoarrays#424 add option to install.sh to download the requested package from a user specified URL
  • Prevent developer's advanced Makefiles and GASNet directory from being distributed with release tarballs

Installation

Please see the installation instructions for more details on how to build and install this version of OpenCoarrays


GitHub forks GitHub stars GitHub watchers Twitter URL