Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Nov 14 20:49
    letmaik opened #39
  • Oct 25 09:35

    szaghi on master

    update submodules update travis config (compare)

  • Oct 25 09:30

    szaghi on master

    update submodules (compare)

  • Oct 25 09:19

    szaghi on master

    update submodules update travis config (compare)

  • Oct 21 06:34
    rakowsk commented #7
  • Oct 20 16:09
    unfurl-links[bot] commented #7
  • Oct 20 16:09
    rakowsk commented #7
  • Oct 12 17:49
    ShatrovOA commented #38
  • Oct 11 15:25
    szaghi labeled #38
  • Oct 11 15:25
    szaghi assigned #38
  • Oct 11 15:25
    szaghi commented #38
  • Oct 11 13:52
    ShatrovOA edited #38
  • Oct 11 13:44
    ShatrovOA opened #38
  • 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
Chris MacMackin
@cmacmackin
@giacombum I'm of the opinion that abstract procedures should only be used when the implementations have the same interface. This requirement is not peculiar to Fortran but is intrinsic to all object-oriented languages. The optional argument choice strikes me as really bad. If you are dealing with a polymorphic variable of this type, then you won't know which argument you should be passing. To be honest, there isn't really any point in having an abstract procedure if it won't have the same interface in all implementations.
Stefano Zaghi
@szaghi
@cmacmackin I disagree. In FOODIE the deferred method for the ODE time derivative as an optional argument, the time t. It reflects very well that the residual function can or cannot explicitely depend on time. If the concrete ODE has U_t=R(U(t)) than you will not pass t to the method %time_derivative, on the contrary if U_t=R(U(t), t)) you will pass t. So, the API is not unique, but the usefulness of having an abstract is tremendus. I am not so rigorous in exploiting abstract.
Chris MacMackin
@cmacmackin
That may be areasonable exception. What I'm objecting to is more the idea of using one optional argument in one implementation and a different one in another. At that point i I don't see the point of using a deferred procedure.
Stefano Zaghi
@szaghi
@cmacmackin :+1: right, I agree with this concept. Indeed, I think at the deferred as a contract: concretes MUST give me this deferred, I could be not aware what you do inside it (thus optionals), but give me it... yes there is space for bad programming...
Stefano Zaghi
@szaghi

Dear All @/all , I have done some steps over with FoXy.

Presently, it has basic capabilities for parsing and emitting XML files (tags). Currently, there is only limited SAX-like facilities (nested tags can be searched/retrieved, but there is not a real tree-representation, all is done by string-parsing on the fly).

I would like to implement also (limited) DOM-like capabilities.

Are there experts on XML parsers and SAX-DOM "approaches"?

I need good feed to learn about well-established XML parsers. Currently, I have been mostly inspired by Python Yattag module that is (manly) a very easy (html/xml) tag emitter, but for FoXy I need to be inspired by more complete XML parsers.

I have not yet studied the other Fortran XML parsers available on the web, but I will do it soon. I am not sure if here there are the authors of those Fortran libraries, but in case your help is very appreciated.

My best regards.

Izaak "Zaak" Beekman
@zbeekman
I have zero experience with it but I think Arjen Markus' FLIBS (or whatever it's called has some XML capabilities). I personally much prefer using JSON or YAML but realize that having the ability to interface with XML is a good thing.
Stefano Zaghi
@szaghi
@zbeekman thanks, yes XML is not friendly as JSON or YAML but it is a standard widely diffused, e.g. I have to use it in VTK. I am studying Arjen and others works: SAX-like approach is in my radar (some events are missing, but I am close to them), whereas DOM needs more work (maybe I will use FIAT to this aim). See you soon.
Stefano Zaghi
@szaghi

OFF TOPIC

Not strictly related to Fortran, but @cmacmackin has published an interesting poster presentation about his research. There is also a more detailed report here. @cmacmackin can I suggest to you to open a gitter chat about Ice Shelves, maybe on the framework of ISOFT? My best compliments :clap:
Stefano Zaghi
@szaghi

Coarray and PETSc

Dear All,
I would like to know your opinions. We ( @francescosalvadore @andreadimascio and me) have started a new interesting Fortran project for solving PDE. The project is under the very-early-borning phase where we are trying to define the main design specifications, however we are already taking some strategic decisions for the future developments. In particular we are disccussing about the parallelization strategy: we would like to exploit PETSc to perform some critical computations. However, we would also like to adopt coarray (over MPI) for other stuffs.

Do you have any experience on using PETSc, in particular within coarray? @zbeekman @muellermichel @afanfa @rouson @nncarlson I think you are the most experienced in this parallel contest, do you have any advices on PETSc/Coarray mixing? There is a better library than PETSc already supporting Coarray?

Thank you @/all for your help.

Damian Rouson
@rouson
@szaghi, mixing CAF and any MPI code should work fine. One of the great things about coarrays is the way they integrate with non-coarray code. All coarrays are actually local data structures. They just happen to be local data that are accessible remotely. You can drop the square braces from a reference to a coarray and pass the local elements into PETSc or into MPI or any other library that doesn't need to know anything about the fact that the data you're passing just happen to be part of a coarray. Of course, it's up to you to handle any necessary synchronization to make the approach work.
Please let us know what algorithms you're interested in using in PETSc. For a linear algebra library that is Fortran all the way down, I recommend checking out PSBLAS, develop by the research group of Alessandro's former Ph.D. advisor. The 3.x versions of PSBLAS use object-oriented Fortran 2003 (and also contain some GPU code that Alessandro wrote). And we currently have a developer working with Alessandro to enhance the gfortran/OpenCoarrays to support for allocatable components of derived type coarrays.
Stefano Zaghi
@szaghi
@rouson Thank you very much for your insight. You are right, presently, we are looking at PETSc for an efficient linear algebra solver: I will try to promote PSBLAS into our "group". Just for your knowledge, we are trying to design a library similar (hopefully better) to OpenFOAM in Fortran standard, OOD-TDD on the good experience obtained by FOODIE (P.S. I hope to finish FOODIE's test on Fermi this week). At some point, when the preliminary design of this new library will be working I would like to invite you to review/join our project. My best regards.
Chris MacMackin
@cmacmackin

I've added a massive new release of FORD. Release notes for v5.0.0 are below (although we are now onto v5.0.2 with some bug fixes).

Version 5.0.0

This is a major release and thus has some non-backwards compatible changes, although every effort has been made to keep them minor.

  • The project_dir option in the project file is now src_dir
  • By default, internally declared variables, types, etc. within procedures are now hidden. This can be changed to the old behaviour by specifying proc_internals: true in the project file.
  • Directories specified in the project file using a relative path are now evaluated relative to the location of that file. Previously they were evaluated relative to the location where FORD is run from. Note that relative directories specified via a command-line flag are still evaluated relative to the current working directory.
  • Documentation below a line declaring multiple variables now applies to all of those variables, whereas it previously only applied to the last one on the line.
  • Extensions for preprocessing must now be explicitly specified in the project file using fpp_extensions. This allows extensions to be used which are not necessarily upper-case (Issue #137). Defaults were selected so as to give the same result as the old default behaviour.

New Features:

  • File dependency graphs are now produced, indicating the order in which files must be compiled (Issue #99)
  • Fixed-form code, in files with an extension in fixed_extensions can now be processed (using the fixed2free tool by ylikx)
  • The legacy block data (Issue #147) and common features are now supported
  • Information is now provided on the number of source lines of code (Issue #98)
  • Output now has better support for smaller windows and screens (Issue #103)
  • Inherited public components and type-bound procedures (if they are not overridden) of derived types are now shown
  • A public type's inheritance from a private type is now shown in graphs
  • Environment variables can now be used in Markdown with the syntax ${ENVIRONMENT_VAR_NAME}. If that environment variable exists the text will be replaced by its contents. Otherwise, it will be replaced by an empty string. (Issue #149)
  • the @note, @bug, @warning, and @todo environments are no longer limited to a single paragraph. If an @endnote, @endbug, @endwarning, or @endtodo statement is found (before the start of another such environment) then the environment will end there. Otherwise, it will end with the paragraph it opens in, as before. (Issue #135)
  • Include directories can now be specified with an --include (or -I) flag at the command line (Issue #143)
  • Call-graphs can now identify external procedures located in other files (Issue #140)

Bug Fixes and Miscellaneous:

  • Keys for graphs are now specific to the type of graph being used
  • Improved handling of attributes for types
  • Better handling of permissions for entities used in modules
  • Improved layouts when summarizing procedures
  • Improved descriptions of where time is spent while making documents
Stefano Zaghi
@szaghi

Dear all, generated from a long, interesting discussion on google group, FURY Fortran library has been released... just a small piece of code for doing physical math with meaninful units of measure symbols attached to numbers. A tentative to improve reliability of Fortran computations. For interested Fortraners FURY is here

https://github.com/szaghi/FURY

Note that it being essentially a symbolic algebra library, an overhead is implied on all math: I do not yet quantified this overhead, but there is. The main usage scenario is to "santize" input/output rather than doing HPC...

Cheers.

Milan Curcic
@milancurcic
Stefano I just love your acronyms! :)
Stefano Zaghi
@szaghi

@milancurcic @zbeekman @rouson I am very sorry for my delay about FOODIE progress, there are some open calls at CNR thus I am studing a lot (there is no hope for me, but I have to try), moreover my main work had few great "loads" on my shoulder last months that absorbed all my time :-( I hope that passed this "hot autumn" I can again work on FOODIE. FURY has been my summer-code-toy "thinked" under the sun of Puglia (sud Italy) while Angelica was spleeping (almost never :-). It started as toy for passing few hours and improving my fortran skills, but now I think that Van Snyder was right and such a feature can save us from many errors and loss of time in consistency checks. I spent a lot of hours last days to cleanup the code because I want integrate it into our pre-postprocessors: it could help our students to be more confident on setup the simulations and analize the results.

Indeed the acronym comes after the name: I was programing it as a "fury" with the hope that Angelica did not wake up :smile: only after I played with the name to build a meaningful acronym in topic with library aim, just a fortunate coincidence :smile: A wiseman could say that "the only good part of my codes is the funny name", but I hope to surprise you :smile_cat:

Tom Dunn
@tomedunn
@szaghi Great work on FURY! Just recently I was thinking of making (or trying to make) a unit conversion library for Fortran but I quickly realized if I wanted to do it right it would require a lot more work than I had originally hoped. It looks like FURY could easily be used to do exactly this! I was wondering though, would FURY work with converting units like temperature that not only have a scaling difference but also an offset?
Stefano Zaghi
@szaghi
@tomedunn Hi Tom, sure the converter mode is almost ready... the non pure multiplicative conversion is under developing now (you catched me in my launch break now devoted to fury :smile: ), if I eat less than usual this week I hope to provide you the temperature conversion feature (I am not sure were to place the offset data...)
Tom Dunn
@tomedunn
@szaghi Awesome! Just don't starve! The brain needs food to work too! :smile:
Stefano Zaghi
@szaghi
yes, but my wife like me slender :smile:
Stefano Zaghi
@szaghi

@tomedunn Hi Tom, the week-diet was good... FURY now support temperature like conversions (with an offset) that can be defined by the friendly builtin string parser of the FURY uom and even a totally generic conversion formula that however can be defined less friendly...
for example you can now do the followings

type(uom)       :: dBm            !< dBm unit.
type(uom)       :: mW             !< mW unit.
type(uom)       :: kelvin         !< Kelvin unit.
type(uom)       :: celsius        !< Celsius unit.
type(qreal)     :: q1             !< A quantity.
type(qreal)     :: q2             !< A quantity.
type(qreal)     :: q3             !< A quantity.
type(dBm_to_mW) :: dBm2mW         !< Converter from dBm to mW. 

dBm = uom('dBm = @user mW')
mW = uom('mW')

call dBm%set_alias_conversion(reference_index=1, alias_index=2, convert=dBm2mW)

q1 = 10. * dBm
q2 = q1%to(unit=mW)
test_passed(1) = q2%stringify(format='(F4.1)')=='10.0 mW'
print "(A,L1)", '10.0 dBm = '//q2%stringify(format='(F4.1)')//', is correct? ', test_passed(1)

call q1%unset
call q2%unset
q1 = 10. * mW
q2 = q1%to(unit=dBm)
test_passed(2) = q2%stringify(format='(F4.1)')=='10.0 dBm'
print "(A,L1)", '10.0 mW = '//q2%stringify(format='(F4.1)')//', is correct? ', test_passed(2)

kelvin = uom('K')
celsius = uom('degC<=273.15 + K=celsius>')

call q1%unset
call q2%unset
q1 = 2 * kelvin
q2 = 1 * celsius
q3 = q1 - q2%to(kelvin)
test_passed(3) = q3%stringify(format='(F7.2)')=='-272.15 K'
print "(A,L1)", '2 K - 1 celsius = '//q3%stringify(format='(F7.2)')//', is correct? ', test_passed(3)

call q3%unset
q3 = q2 - q1%to(celsius)
test_passed(4) = q3%stringify(format='(F6.2)')=='272.15 degC'
print "(A,L1)", '1 celsius - 2 K = '//q3%stringify(format='(F6.2)')//', is correct? ', test_passed(4)

Note that while "celsius to kelvin" can be defined very easy by the builtin string parser, the conversion from dBm to mW does not because their conversions are not simply y= offset + factor * x, rather in this case they are

  • dBm = 10 * log(mW)
  • mW = 10**(dBm / 10)

So the user must define this generic conversion and attach to the pre-defined uom (where I have used a placeholder), see the statement

call dBm%set_alias_conversion(reference_index=1, alias_index=2, convert=dBm2mW)

The converter dBm2mW is simply a concrete extension of one (the only for now) abstract class provided by FURY, i.e.

module dBm_to_mW_converter
!< Define the converter (user-supplied) from dBm to mW.
use fury

implicit none
private
public :: dBm_to_mW 

type, extends(converter) :: dBm_to_mW
  !< Converter (user-supplied) from dBm to mW.
  contains
    procedure, nopass :: convert
endtype dBm_to_mW
contains
  pure function convert(magnitude, inverse) result(converted)
  !< User-supplied conversion from dBm to mW.
  real(R_P), intent(in)           :: magnitude !< Magnitude (of the quantity) to be converted.
  logical,   intent(in), optional :: inverse   !< Activate inverse conversion.
  real(R_P)                       :: converted !< Converted magnitude.
  logical                         :: inverse_   !< Activate inverse conversion, local variable.

  inverse_ = .false. ; if (present(inverse)) inverse_ = inverse
  if (inverse_) then
    converted = 10._R_P * log10(magnitude)
  else
    converted = 10._R_P**(magnitude / 10._R_P)
  endif
  endfunction convert
endmodule dBm_to_mW_converter

The above snippet is taken from a FURY test. Unfortunately, I was not able to find a way to pass a generic function without bothering the user: the string parsing has been discarderd because it could be result inefficient at runtime: the multiplicative-like conveters are efficient becuase after the intial parsing they are standard Fortran function (the parsing simply set the value of offset and factor) whereas a runtime evaluation of string-function could be too much overheaded.

Let me know if such an implementation can be useful for you.

Cheers

Milan Curcic
@milancurcic

Hey all,

I just put out a bug-fix release of datetime-fortran: https://github.com/milancurcic/datetime-fortran/releases/tag/v1.4.3

Main update is a workaround for an issue with Intel Fortran which could not access overloaded operators when derived type is imported through an intermediate accessor module. See the specific issue here : milancurcic/datetime-fortran#39

I also filed the issue on the Intel Fortran forum.

Release 1.4.3 builds and passes all tests with gfortran 5.x and ifort 17. Cray tests to follow. If anybody has access and can test it with PGI and IBM compilers, that would be amazing. Thanks!
Stefano Zaghi
@szaghi
@milancurcic great! The probable bug of Intel has afflicted me many times... thank you! Unfortunately my access to IBM vanished...
Milan Curcic
@milancurcic

My dear Fortranners, I just posted a question on SO that has been bugging me on and off for few days now:

http://stackoverflow.com/questions/39643775/passing-a-generic-procedure-to-a-function-as-actual-argument

I am aware quite a few of you can code circles around things like this. Let me know if you have a suggestion and thank you for being amazing.

Stefano Zaghi
@szaghi
@milancurcic I am with you. Indeed, I never tried to pass a generic name as dummy, but close to it. Currently, I am trying to forcing my self to adopt Damian's teaching about OO and in similar cases I am trying to adopt something like strategy pattern, but I do not know if this can fit with your case. Anyhow, I was not aware about the limitations involved in passing generic name as dummy. What solution you have eventually adopted? The wrapper suggested by Vladimir? OHHH, I just see that Vladimir is indeed @LadaF ! We have another guru here :tada: :tada:
Stefano Zaghi
@szaghi

Dear @/all , another very interesting publication by Chris

https://cmacmackin.github.io/pdfs/transferReport.pdf

( @cmacmackin you are too much modest to highlight it and not all read compulsively your blog as me... sorry to spoiler your work, but it is really interesting for me)

Izaak "Zaak" Beekman
@zbeekman
@/all I think we should have a stronger showing here so go vote!
Stefano Zaghi
@szaghi
:+1: done... for C? :smile:
Giacomo Rossi
@giacombum
Well done @szaghi... You better know that language than Fortran... :-D
Stefano Zaghi
@szaghi
@giacombum :smile: poor C and poor Fortran is always better than nothing as you :smile:
Izaak "Zaak" Beekman
@zbeekman

@/all I have been staring at something too long and have started to doubt myself. Can someone please confirm that the following is true for Coarray Fortran:

On a given image if an assignment is performed with an image local variable on the left hand side, and a coarray object on the righthand side (i.e., data on another image) no synchronization is needed before using the local variable on the left hand side because the assignment will not allow that image to proceed until the local variable has received the remote data. i.e., there is no synchronization required between line one and two below:

local_b(:) = remote_a(:)[me+1]
all_match = all( local_b(:) ==  local_a(:) )

This is correct, no? That is local_b will always have the values from remote_a when being compared with local_a, right?

Stefano Zaghi
@szaghi

@zbeekman I really do not know what standard states about this. Have you find an answer? This is interesting also for me, that is,

does your example imply that there is an implicit synchronization between me and me+1 before the 2nd statement?

Or, on the other side of the moon,

to achieve asynchronous parallelism, do I have to assign to a coarray rather than to get/fetch from it?

Izaak "Zaak" Beekman
@zbeekman
@szaghi yes, my current understanding is that gets are blocking for the local image, whereas puts are non-blocking. So to overlap computation and communication and reduce time spent waiting for other images, you should try to have the coindexed object on the LHS of the assignment.
Stefano Zaghi
@szaghi
@zbeekman :+1:
Izaak "Zaak" Beekman
@zbeekman
@/all If any one wants to try nightly GFortran builds from GCC trunk, you can do so very easily with my nightly-gcc-trunk-docker-image project
I use my other project to trigger nightly builds of the docker image: https://github.com/zbeekman/nightly-docker-rebuild
Milan Curcic
@milancurcic
Thanks @zbeekman I made note of this. It will come very useful when I start playing with gcc7 (haven't yet). Started playing with docker containers recently and absolutely love them!
Izaak "Zaak" Beekman
@zbeekman
@milancurcic great! Feel free to star/watch/fork!
Stefano Zaghi
@szaghi
@zbeekman Thank you very much. I already (ad)used of gcc 7, but having your nightly build system is awesome. The cons is that I have to learn docker and my time is nearly to vanish...
Izaak "Zaak" Beekman
@zbeekman
@szaghi well docker is pretty simple... you use it as a virtual machine essentially, that has GCC 7 trunk installed in it. Get docker installation instructions for Arch Linux here and then once it's installed and the docker engine is running just docker pull zbeekman/nightly-gcc-trunk-docker-image:latest and then to run it, and mount a local directory, say with some source code: docker run -v /local/code/source:/mount/path/on/vm -i -t zbeekman/nightly-gcc-trunk-docker-image If you want root, add --user root to that, so you can install some packages etc... Although I may give the default user sudo priviledges soon...
Stefano Zaghi
@szaghi
@zbeekman Great! Thanks!
Chris MacMackin
@cmacmackin
Hi all. I'd like to make a small announcement that I am releasing a simple logging library for Fortran, called Flogging. This is licensed under the LGPL. The easiest way to install this is using the FLATPack repository (which is still in an embryonic stage) with the Spack package manager.
Stefano Zaghi
@szaghi
@cmacmackin
Stefano Zaghi
@szaghi
@cmacmackin Flogging is very intersting (damn, I have missed, you announcement is fundamental!!!???!!). I have to study it because I have never used Python's logging library. A wild question (before study it): using it in a parallel env is viable? It could be very handy for debugging my CAF experiments...
Chris MacMackin
@cmacmackin
I haven't put much thought a parallel environment. As it stands now, I'm pretty sure each image would end up creating its own log-file, which isn't really ideal. I'll also probably need to change the IO slightly to make it thread-safe.
Stefano Zaghi
@szaghi
@/all Happy Crhistmas ! :santa:
Stefano Zaghi
@szaghi

@/all @jacobwilliams

Multidimensional interpolation on non uniform grid

Dear all,
I am now approaching to implement some interpolation procedures for some different purposes:

  • for WENO reconstruction with @giacombum;
  • for mesh-to-mesh solution interpolation;

I am a fun of @jacobwilliams interpolotars and, indeed, I had already planned to use his libraries. However, I have just realized that for my needs two keys are necessary

  • multidimensional;
  • non uniform grids spacing;

Before reinventing the wheel or re-study the state-of-the-art litterature, are you aware of such a kind of interpolator libraries? Obviusly, FOSS and possible in Fortran (or Fortran-friendly).

Jacob's libraries (bspline in particular) is currently my best option: our mesh are in general very slowly-changing that can be viewed (approximated/considered) as locally uniform, but for the WENO aim a non uniform interpolator can be very useful just for only study aims.

Happy new years :tada: :tada:

Milan Curcic
@milancurcic

@szaghi I have been using ESMF for years for interpolation, take a look at their capabilities: https://www.earthsystemcog.org/projects/esmf/regridding_esmf_6_3_0rp1

Pros:

  • parallel (MPI), including different domain partitioning between source and target grids
  • works for both structured and unstructured grids.
  • has a CLI tool for regridding

Cons:

  • Quite large project if you need only interpolation
  • Only 2-d and 3-d interpolation supported AFAIK
  • No fancy interpolation methods - just nearest neighbor, bilinear, and conservative.

ESMF is probably not something you will want to use, but I recommend you look at it for inspiration, especially how it handles the grid-to-grid interpolation in parallel and interpolating between different domain partitions.