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
@szaghi another idea I like is store data very compactly with direct access IO binary files. Then store meta-data in a self describing way using JSON (JSON-Fortran) or, if you must, XML. So you can store raw blocks of variables (an ordered list of vectors of node or cell centered variables) and then either have 1 file per processor or use direct access to index into each file in the appropriate location. Obviously the connectivity info is also challenging if you're using unstructured.
@/all Travis-CI supports community contributed and supported languages. See: https://github.com/travis-ci/docs-travis-ci-com/blob/gh-pages/user/languages/community-supported-languages.md They require a team of at least three people to be maintainers and contributors with the expertise etc. It would be great if @szaghi @rouson @jacobwilliams @milancurcic @cmacmackin or anyone else here were interested in helping out with this. Setting up a sane config for fortran would hopefully make it less of a yak shave to get started using Fortran on Travis-CI. Please let me know if you are interested.
Stefano Zaghi
@szaghi
@zbeekman Thanks for the hints on IO, I'll discuss about this with @giacombum and @francescosalvadore For the Travis support I surely offer my (poor and scattered) support, but I could not be up to the task: I have to carefully read the mission, later today I'll give you an answer. Cheers
Stefano Zaghi
@szaghi

@zbeekman

Dear Zaak, I am trying your docker image for having a very fresh build of gfortran... it is very fancy, your image has been installed and ran very smoothly in my Arch Linux, thank you very much!

I am very new to docker, I have not read all docs... my apologize if my following question is very silly. Running your image mounting a source_path is handy for testing that source with a new gfortran, but it is tedius to stop the image and run it again with another source path. It would be very handy to use your docker image like I do with python virtualenv: run the image to have the new gfortran and use it on my whole system, not only into 1 mounted path.

Is it possible to run a docker image on the whole file system? Or at least is safe to mount one partition as source_path, say to mount /home/stefano?

Cheers

Stefano Zaghi
@szaghi

@zbeekman Maybe I found an answer

https://www.theodo.fr/blog/2015/04/docker-and-virtualenv-a-clean-way-to-locally-install-python-dependencies-with-pip-in-docker/

It seems that I can mount some paths of a running-docker-image into my system. If this is true, I can mount your (docker image) gfortran-PATH somewhere in my system (say /opt/zaak-gfortran/) and then load it as my other modules... I'll try later today.

Cheers

Stefano Zaghi
@szaghi

@zbeekman

Zaak, I am sorry to bother you, but docker remains ambiguous for me.

See this guide

https://docs.docker.com/engine/getstarted/step_three/#/step-2-run-the-whalesay-image

It seems it is possible to use docker to directly run a program (the shell program whalesay in that case) in the host system, i.e.

docker run docker/whalesay cowsay 'hello Zaak'

So my new question: is it possible to dockerize gfortran in that way? say to be able to run

docker run zaak/gfortran 'foo.f90 -o foo'

Cheers

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.