by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Mar 26 17:48

    szaghi on master

    update submodules (compare)

  • Mar 25 13:39

    szaghi on master

    update submodules (compare)

  • Nov 14 2019 20:49
    letmaik opened #39
  • Oct 25 2019 09:35

    szaghi on master

    update submodules update travis config (compare)

  • Oct 25 2019 09:30

    szaghi on master

    update submodules (compare)

  • Oct 25 2019 09:19

    szaghi on master

    update submodules update travis config (compare)

  • Oct 21 2019 06:34
    rakowsk commented #7
  • Oct 20 2019 16:09
    unfurl-links[bot] commented #7
  • Oct 20 2019 16:09
    rakowsk commented #7
  • Oct 12 2019 17:49
    ShatrovOA commented #38
  • Oct 11 2019 15:25
    szaghi labeled #38
  • Oct 11 2019 15:25
    szaghi assigned #38
  • Oct 11 2019 15:25
    szaghi commented #38
  • Oct 11 2019 13:52
    ShatrovOA edited #38
  • Oct 11 2019 13:44
    ShatrovOA opened #38
  • Sep 19 2019 11:19
    szaghi commented #7
  • Sep 19 2019 11:08

    szaghi on master

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

  • Sep 19 2019 11:06

    szaghi on fix-parsing-bug-issue#7

    (compare)

  • Sep 19 2019 07:54

    szaghi on fix-parsing-bug-issue#7

    (compare)

  • Sep 19 2019 07:52
    szaghi commented #7
Izaak "Zaak" Beekman
@zbeekman
Hi Stefano, let me get back to you. I'm pretty sure it shouldn't be too hard to set this up so you can invoke GFortran directly from Docker (like whalesay) however, the compiled code may not run natively on your system outside docker due to glibc, libgfortran etc.
Also, I think you shouldn't have any problem just mounting your entire home directory in docker, except, perhaps, runtime issues if you try to natively run code you compiled with docker.
Izaak "Zaak" Beekman
@zbeekman
Stefano, yes it is possible to implement what you're asking... I can try to make an additional tag to provide gfortran, gcc and g++ (each) that will share the same image components except for ENTRYPOINT and CMD
but in the mean time, if you pass something like -c "gfortran --version" or -c "gfortran /path/to/mounted/source/file.f90 && /path/to/mounted/source/a.out" you should be able to use dockerized gfortran with the image as it stands
Izaak "Zaak" Beekman
@zbeekman
At some point I'll look into providing direct calls into gfortran/gcc/g++ but not for a while probably
Izaak "Zaak" Beekman
@zbeekman
Basically the entry point is the command that the image runs, in this case /bin/bash and the CMD is -l which is the default arguments to be passed to the ENTRYPOINT. If you add extra text after docker run .... it will replace CMD with that extra text. So you can run arbitrary commands by passing either -c "my raw bash commands here like calls to /usr/local/bin/gfortran" or you could pass it a script that is somewhere already cross mounted with the container.
Hope this helps, @szaghi
Stefano Zaghi
@szaghi

@zbeekman
Thank you very for your kind replays.

Today I played with docker for learning aims... I tried to achieve a sort of cross-compiling without success, but I had few minutes for my tests, I hope to be more lucky tomorrow. However, I have a request for you: I tried to compose your image with another providing python 2.7, but docker-compose is really non intuitive (IMO) and it seems not so trivial at least at the beginning; can you modify your image to include a python 2.7 interpreter? Without a python interpreter I cannot use FoBiS thus my productivity becomes close to zero... having a python interpreter into your gcc docker image let me to source any virtualenv I created for each Fortran project... it will become very handy.

Cheers

Izaak "Zaak" Beekman
@zbeekman
I haven't tried docker compose yet, I just write dockerfiles by hand. I'll add python 2.7, pip and FoBiS.py to the image that nightly gcc is based on, then you'll have it.
Stefano Zaghi
@szaghi
@zbeekman Great! Thank you very much! :tada: :tada: :tada:
Izaak "Zaak" Beekman
@zbeekman
@szaghi try pulling the latest docker image... it has python and pip and it should install to ~/.local so you can get a virtual env up and running that way.. Let me know if for some reason it's not working as expected
Stefano Zaghi
@szaghi
@zbeekman ok, I try it immediately
Stefano Zaghi
@szaghi

@zbeekman,

Dear Zaak, it works perfectly! Thank you very much!!!!! :tada: :tada: :tada:

victorsndvg
@victorsndvg
Sorry all because I'm not often reading this thread ...
@szaghi , related with HDF5 and parallel IO with fortran, maybe you can be interested in XH5For. I've experienced good scalability with it. If you need, I can help you with the first steps! ;)
Stefano Zaghi
@szaghi

@victorsndvg
Dear Victor,
indeed I am studying your library in these days, it is cool. Do you think that an AMR structure (a hierarchy of refined multi-block domain) can be easily represented into your XDMF format? My IO involves hexaedron cells with variables saved at vertex and/or at center (and probably in the future also some at face). Currently, I implemented a dirty solution as Zaak suggested: a stream-unformatted file where each process can direct do IO into its own position. Not yet tested in parallel, thus it will probably do not scale decently (it is no based in MPI IO). For the moment, I am good with this IO: I am developing a new CFD code from scratch, thus I am doing a lot of serial tests, but when the code will reach a critic mass, I'll start to do parallel tests; at that time I'll decide which way do: 0) my own dirty stream file, 1) MPI IO, 2) HDF5, 3) some other good library like your.

For the moment I have to study... Do you think your library can satisfy my needs (parallel AMR on block-structured hexaedrons)?

victorsndvg
@victorsndvg
First of all I have to say that the library was created because libxdmf (http://www.xdmf.org) is much more than a simple IO library, for me it was difficult to deal with it and also because the fortran layer was not mature enough when I started to develop XH5For (I don't the current status)
XH5For is a light-weight layer, you only have to pass the number of nodes and elements, and its correspondent arrays per task and it write the data into a HDF5 file per timestep
it does nothing more
Not true, it also communicate the number of elements and nodes per task. The library only use broadcasts and allgathers
victorsndvg
@victorsndvg
In this schema you can write nodal and elemental fields of this types of elements and some more. Ofcourse hexahedron cells are included and fully tested
Unstructured and structured meshes are supported
Face fields are not supported
victorsndvg
@victorsndvg
Thats all I think ...
I don't know exactly what do mean when you say AMR in terms of the mesh file. XH5For it only writes raw meshes and fields. There is not yet implemented the writing of any extra-metadata like boundary conditions or vicinity
The last note: It also works sequentially! ;)
Stefano Zaghi
@szaghi

The last note: It also works sequentially!

This is a great plus... but how do it? to my knowledge, you have to select between HDF5 and Parallel HDF5 a priori...

Indeed, yes, my dirty solution relies on an header where a sort of metadata defines the hierarchy of mesh saved. Without such an information it becomes cumbersome to reconstruct the AMR grid, that can changes step by step. I can save the metadata into a separate file, but this is also not much nice
Anyhow, I'll study you library with much more care soon
cheers
victorsndvg
@victorsndvg
CMake compilation system is on the one in charge of detecting if the HDF5 installation is parallel or not
I can study the way to write "custom data" into the HDF5/XDMF files. I will tell you if I have some news
Giacomo Rossi
@giacombum
Hi @/all : does anyone know if assumed rank array is fully supported from recent Intel (16, 17) and gnu (6, 7) compilers?
Stefano Zaghi
@szaghi

@giacombum With the test you sent me, Intel 17.0.3 generates a catastrophic error and GNU 7.0.1 says

Error: Assumed-rank variable arr2 at (1) may only be used as actual argument

Maybe, this is not the correct usage. If I recall well, this feature is intended to facilitate C-interop...

Giacomo Rossi
@giacombum
yes, this feature is always linked to C-interop...
@szaghi the errors are the same (catastrophic with Intel and compiling error with GNU) with Intel 16.0.3 and GNU 6.3.1
Giacomo Rossi
@giacombum
Hi @/all, I don't remember if here someone had posted a link with a guide for installing gcc6 on debian: I've tried to search on internet with no luck...
victorsndvg
@victorsndvg

@giacombum , I don't know which are the particular issues in debian, but there is an application that could help you to easy install scientific software, easybuild.

I've never checked it before, but I'm exited about it.

There are several versions of gcc, you can see them in the following link:
http://easybuild.readthedocs.io/en/latest/version-specific/Supported_software.html#list-software-gcc-205

hope it helps!
Giacomo Rossi
@giacombum
@victorsndvg thanks, easybuild sounds very intresting!!! Anyhow, I refer to pre-builded packages available for debian... Well, I'm getting older, my memory isn't so good :smile:
victorsndvg
@victorsndvg
In my home laptop I've the debian testing distribution and I think that I already have 6.3.0.
If you can wait till the night, I can look later which are my sources list
Stefano Zaghi
@szaghi

@/all

Dear all, this is an help request for expert readers of Fortran Standard (like @zbeekman @rouson ...) : if you have the time, can you let me know if the following snippet is standard?

   subroutine solve(self, eos_left, state_left, eos_right, state_right, normal, fluxes, pattern)
   !< Solve Riemann Problem.
   !<
   !< Approximate Riemann Solver based on (local) Lax-Friedrichs (known also as Rusanov) algorithm.
   class(riemann_solver_llf),     intent(inout)         :: self         !< Solver.
   class(eos_object),             intent(in)            :: eos_left     !< Equation of state for left state.
   class(conservative_object),    intent(in)            :: state_left   !< Left Riemann state.
   class(eos_object),             intent(in)            :: eos_right    !< Equation of state for right state.
   class(conservative_object),    intent(in)            :: state_right  !< Right Riemann state.
   type(vector),                  intent(in)            :: normal       !< Normal (versor) of face where fluxes are given.
   class(conservative_object),    intent(inout)         :: fluxes       !< Fluxes of the Riemann Problem solution.
   class(riemann_pattern_object), intent(out), optional :: pattern      !< Riemann pattern.
   type(conservative_compressible), pointer             :: state_left_  !< Left Riemann state, local variable.
   type(conservative_compressible), pointer             :: state_right_ !< Right Riemann state, local variable.
   type(conservative_compressible)                      :: fluxes_left  !< Fluxes of left state.
   type(conservative_compressible)                      :: fluxes_right !< Fluxes of right state.
   type(conservative_compressible)                      :: fluxes_      !< Fluxes, local variable.
   type(riemann_pattern_compressible_pvl)               :: pattern_     !< Riemann pattern.
   real(R8P)                                            :: lmax         !< Maximum wave speed estimation.

   call pattern_%compute(eos_left=eos_left, state_left=state_left, eos_right=eos_right, state_right=state_right, normal=normal)
   lmax = maxval(abs(pattern_%waves_extrema()))
   call state_left%compute_fluxes(eos=eos_left, normal=normal, fluxes=fluxes_left)
   call state_right%compute_fluxes(eos=eos_right, normal=normal, fluxes=fluxes_right)
   state_left_ => conservative_compressible_pointer(to=state_left)
   state_right_ => conservative_compressible_pointer(to=state_right)
   select type(fluxes)
   type is(conservative_compressible)
#ifdef __GFORTRAN__
      fluxes = 0._R8P * (fluxes_left + fluxes_right - (lmax * (state_right_ - state_left_)))
#else
      ! Intel Fortran has issue in resolving the equation with multiple operators... it must be split
      fluxes_ = state_right_ - state_left_
      fluxes_ = lmax * fluxes_
      fluxes = fluxes_left + fluxes_right
      fluxes = fluxes - fluxes_
      fluxes = 0._R8P * fluxes
#endif
   endselect
   if (present(pattern)) then
      select type(pattern)
      type is(riemann_pattern_compressible_pvl)
         pattern = pattern_
      endselect
   endif
   endsubroutine solve

The full story can be read here on google group, but in few words, Intel Fortran does not accept the simple equation and I have to split it.

I suspect that this is a compiler bug, but I like to know your opinion.

Cheers

Stefano Zaghi
@szaghi

@zbeekman Zaak I am not able to pull your latest docker image, I got

Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io: No address associated with hostname

Is it my issue, or something is changed?
Cheers

Damian Rouson
@rouson
I too suspect it is a compiler error and I'm not totally surprised given past errors I've seen with Intel. I would help, however, to see the error message. I suggest reducing it further and submitting a bug report to Intel. I also recommend inquiring about whether you can be put on their list to become a beta tester when the next beta program starts. They usually run a beta test program starting around March and ending around September so hopefully it will happen soon. They give a high priority to bugs reported on the beta version. I heard one piece of good news: apparently the next Intel release will be fully Fortran 2008 compliant. They'll be the second compiler to reach that exciting goal.
Stefano Zaghi
@szaghi

@rouson Dear Damian, the minimal working example has been already done (not by me, but by a very nice Fortraner) and submitted to intel developers attention. It happened that this is really an intel bug and, more funny, it is of the same nature of another issue I faced within @francescosalvadore and for which he created this report. I was in the beta testing last year, I'll probably be also in the next. It is wonderful that intel will be fully compliant with 2008 standard!

Aside, I faced today with a probable bug with GNU gfortran 6.3.1 (and 7.0.0, not able to test against the Zaak nightly build). The (probable) bug is related to abstract types... I hope to be able to isolate a simple example monday.

My best regards.

Izaak "Zaak" Beekman
@zbeekman
@szaghi Are you still having issues with the docker image? If so, what is the command you are running that gets that respons?
Stefano Zaghi
@szaghi
@zbeekman today I cannot do anything of some interest, tomorrow I'll try and I'll let you know about my test. Thank you as always.
Stefano Zaghi
@szaghi
@zbeekman Zaak, I still have problems, but it depends on my side, I think I had broken my docker installation: Monday, I'll reinstall docker and I'll give you my feedback. Have a good weekend!
Stefano Zaghi
@szaghi

@zbeekman
Dear Zaak, I can confirm, the issue was due to my broken docker installation

┌╼ stefano@zaghi(10:55 AM Mon Mar 27)
├───╼ ~ 32 files, 6.3Mb
└──────╼ docker pull zbeekman/nightly-gcc-trunk-docker-image
Using default tag: latest
latest: Pulling from zbeekman/nightly-gcc-trunk-docker-image
5f2c9defd8b5: Pull complete
676f34be0213: Pull complete
eecb0076700b: Pull complete
8c856ba4f4c6: Pull complete
97f9497af1ef: Pull complete
Digest: sha256:7869ca6419b3f554392f72cc1cd0b90449dbe374b6bbb9cd80cb91e76e4d3960
Status: Downloaded newer image for zbeekman/nightly-gcc-trunk-docker-image:latest
╼ stefano@zaghi(10:56 AM Mon Mar 27)
├───╼ ~ 32 files, 6.3Mb
└──────╼ docker images
REPOSITORY                                TAG                 IMAGE ID            CREATED             SIZE
zbeekman/nightly-gcc-trunk-docker-image   latest              614b0749b3db        2 hours ago         579 MB
hello-world                               latest              48b5124b2768        2 months ago        1.84 kB

Thank you!

Stefano Zaghi
@szaghi

Hi @/all ,
there is anyone here that is expert (or at least who has already used) multi-step ODE integrator with variable time step-size? Maybe @jacobwilliams with DDEABM or other libraries? I searched for good references on sciencedirect, but after an hour I did not find anything really interesting?

In particular, I am interested on Strong Stability Preserving multi-step Runge-Kutta solvers to achieve an ODE solver of at least 8th formal order of accuracy that preserves stability features to deal with discontinuous solutions. However, in the literature it seems that such a scheme has been developed for only fixed time step (probably because the varying time step was juiced to be too costly). Before spent my time to (re)compute the linear-multi-step coefficients I like to know if some of you can point me to good references.

My best regards.