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
From the changelog:

New features:

  • Arbitrary preprocessor can now be specified (Issue #117, PR #129)
  • CPP now used as default preprocessor instead of gfortran, as former is more widespread (note that this should not
    change results of preprocessing)
  • Pages now ordered according to file-name (Issue #121, PR #122)
  • Integration of Gitter sidecar
  • Optionally print date documentation created in the page footer (PR #115)
  • Can export graphs as SVG images and graphviz source (Issue #97)
  • Single global switch now available to hide local variables, derived types, etc. within procedures (Issue #100)
  • Support for coloured edges in graphs, which can make it easier to read large graphs (Issue #113)

Bug fixes:

  • \g in character literal no longer causes crash (Issue #136)
  • No longer interprets concurrent in do concurrent as function call (Issue #131)
  • Header doesn't cover links to particular lines of source code in source file pages (Issue #132)
  • Copying file trees now works on network file systems (Issue #128)
  • :: now accepted in all use statements (Issue #120, PR #123)
  • deferred now included in lists of type-bound procedure attributes
  • Correct handling of include paths with user's home directory specified by ~ (Part of issue #134)
  • Correctly interprets output from preprocessors when running with Python 3 (PR #129)
  • Can now copy file hierarchies deeper than 10 directories (PR #127)
  • MathJax now works for both HTTP and HTTPS (PR #126)
Stefano Zaghi
@szaghi
Dear all,

I have created a skeleton page for list Group's member

Fortran-FOSS-Programmers/Fortran-FOSS-Programmers.github.io#5

I hope you like it.

See you soon.

P.S. @cmacmackin great!

Stefano Zaghi
@szaghi

Help Wanted for polymorphic arguments!

My dear, I have a trivial question to which I am not able to respond... I need your help

Let us suppose we an subroutine that among others accept 3 unlimited polymorphic dummies

subroutine foo(arg1, arg2, arg3, ...)
class(*), intent(in) :: arg1
class(*), intent(in) :: arg2
class(*), intent(in) :: arg3
...
end subroutine foo

Before using the arg# I have to check their type/class, right? so something like

subroutine foo(arg1, arg2, arg3, ...)
class(*), intent(in) :: arg1
class(*), intent(in) :: arg2
class(*), intent(in) :: arg3
...
select type(arg1)
type is(integer)
    select type(arg2)
    type is(integer)
      select type(arg3)
      type is(integer)
           ! do my integer stuff
      end select
    end select
end select
end subroutine foo

That is very verbose and error-prone. In the case I am sure that the combination of arg# is always uniform, namely they are ALL integers, reals, complexs... and I never fall into the case that one is real and others are integers, two are reals and the last is integer and similar etherogeneous cases, there is something smarter that I can do? I am confident that there is no other way to deal with unlimited polymorphic other than select type, but I prefer to listen this from your voice :smile:

Thank you far any comments!

Tom Dunn
@tomedunn
I think I would just write a separate subroutine for each type of argument and then overload a generic subroutine to call them all via the same subroutine. It doesn't allow you to reuse the code between the subroutines but it does allow you to get rid of the nested select type statements.
Stefano Zaghi
@szaghi
Hi @tomedunn thank you for your help. Yes, generic name and dynamic dispatch was my first approach, but then I come to unlimited polymorphic just to avoi to write tons of foo_real_64, foo_real_32, foo_integer_32... where only few statements differ (again error-prone). Indeed I have written a pre-processor just for this case, but I have write a piece of code with a minimum dependency for easy-sharing and adding a pre-processor dependency is not a viable approach. Anyhow thank you very much!
Chris MacMackin
@cmacmackin
The nested select type blocks is the only way to do it. I don't find unlimited polymorphics to be especially useful, for this reason. At the end of the day, the issue here is that Fortran lacks generic programming facilities. Any attempt to replicate that functionality will be messy.
Stefano Zaghi
@szaghi
@cmacmackin Thanks, I should know this, but I was hoping to have missed something... I know that you prefer transfer workaround (I have studied FIAT even I still have not find the time to contribute to it) and I have to admit that you are right. In this case, I think I will go with the old overloading of generic names with a tons of foo_xxx. Thank you all for your help.
Stefano Zaghi
@szaghi
@cmacmackin @tomedunn @zbeekman and all, sorry to bother you again. Lefting the unlimited polymorphic approach, I am now wondering if the assumed rank arrays can help me to avoid code-duplication. I know that assumed rank arrays, e.g. real, intent(in) :: x(..) have been introduced for a better C-interop, but I am wonderding if they can help me. There are some cons in their usage? Copy-in-out? I never used them, something of you do this? Thanks in advance!
Stefano Zaghi
@szaghi

Universal Linux Package

@giacombum pointed out this interesing project

http://snapcraft.io/

I know that @rouson @zbeekman and Co. have done a lot of work in packaging OpenCoarrays, maybe this project can be of any help for them and others.

My best regards.

Giacomo Rossi
@giacombum
and if this can be helpful also for all our Fortran projects?
Chris MacMackin
@cmacmackin
From what I recall, assumed-rank isn't all that useful, for much the same reason that unlimited-polymorphics aren't that useful. Assumed size may work better for you.
Stefano Zaghi
@szaghi
@cmacmackin :worried: Thanks!
Izaak "Zaak" Beekman
@zbeekman
Yes I was excited about assumed rank until I started learning more about it... Seems mostly only useful for its intended C interop functionality
BTW the latest versions of FORD and JSON-Fortran are in Homebrew thanks to @cmacmackin's dedication and hard work to resolve a few issues.
Giacomo Rossi
@giacombum
Dear all, I've a question regarding deferred procedures and concrete types: in an abstract type I've declared an abstract procedure, that I want to use in two different concrete types. Obviously, in the two concrete types, the procedure does the same thing, but in a different manner (because of the differences between concrete types), so it needs arguments of different type or different rank... How can I overcome this problem?
One (bad) workaround could be to declare the deferred procedure into the abstract type with a lot of optional arguments, but it seems too bad also for me :-)
Stefano Zaghi
@szaghi
To whom it may concern, the new version of FoBiS v2.0.2 now supports SUBMODULES: also projects that rely on submodules can be automatically built by means of FoBiS, see https://github.com/szaghi/FoBiS. My best regards.
Stefano Zaghi
@szaghi

@giacombum
To my knowledge ALL deferred TBP must be implemented in a valid concrete extension of an abstract type. So I think you have 2 alternatives:

Optionals abuse

The abstract interface must consider all the optional arguments...

module foo_t
type, abstract :: foo
contains
  procedure(bar_interface), deferred :: bar
end type foo
abstract interface
  subroutine bar_interface(self, arg1, arg2)
  import :: foo
  class(foo), intent(in) :: self
  integer, intent(in), optional :: arg1
  integer, intent(in), optional :: arg2(1:)
  end subroutine bar_interface
end interface
end module foo_t

module foo_concretes
use foo_t
type, extends(foo) :: concrete1
contains
  procedure :: bar => bar_concrete1
end type concrete1 

type, extends(foo) :: concrete2
contains
  procedure :: bar => bar_concrete2
end type concrete2

contains
  subroutine bar_concrete1(self, arg1, arg2)
  class(concrete1), intent(in) :: self
  integer, intent(in), optional :: arg1
  integer, intent(in), optional :: arg2(1:)
  ! use only arg1, arg2 is never used
  end subroutine bar_concrete1

  subroutine bar_concrete2(self, arg1, arg2)
  class(concrete2), intent(in) :: self
  integer, intent(in), optional :: arg1
  integer, intent(in), optional :: arg2(1:)
  ! use only arg2, arg1 is never used
  end subroutine bar_concrete2
end module foo_concretes

In the case the dummy arguments are many this approach is not concise, neither clear.

Avoid the deferred at all

This makes the abstrac less clear, the contract becomes not explicit, but the concretes are not polluted by never-used optionals

module foo_t
type, abstract :: foo
  ! for developers: rember to implement a concrete bar!
end type foo
end module foo_t

module foo_concretes
use foo_t
type, extends(foo) :: concrete1
contains
  procedure :: bar => bar_concrete1
end type concrete1 

type, extends(foo) :: concrete2
contains
  procedure :: bar => bar_concrete2
end type concrete2

contains
  subroutine bar_concrete1(self, arg1, arg2)
  class(concrete1), intent(in) :: self
  integer, intent(in) :: arg1
  ! use only arg1
  end subroutine bar_concrete1

  subroutine bar_concrete2(self, arg2)
  class(concrete2), intent(in) :: self
  integer, intent(in) :: arg2(1:)
  ! use only arg2
  end subroutine bar_concrete2
end module foo_concretes
Giacomo Rossi
@giacombum
Well, both approaches seems to have pros and cons, and you have highlighted them... is there any other opinion? I prefer the second one: more clean.
Stefano Zaghi
@szaghi

@/all Dear all, do you have a VIM syntax file for Fortran supporting submodule related syntax?

In particular, let us consider the following snippet:

submodule (foo) bar
contains
  module subroutine foo_bar
  ...
  end subroutine foo_bar
endsubmodule bar

I want:

  • highlight submodule and endsubmodule;
  • enable folding of module subroutine/end subroutine and module function/end function.

Thank you in advance!

P.S. @giacombum I have not a particular preference for your question, it depends on how many arguments are optional.

@tomedunn I see that you have two different Fortran vim syntax. Which is the best among them? The update time is very close...

https://github.com/tomedunn/vim.modfortran => Aug 16, 2015
https://github.com/tomedunn/vim.fortran => Jul 11, 2015

Tom Dunn
@tomedunn
I think the second one is the one to go with. I can't say I've dealt with them that much since I uploaded them. The first one, vim.modfortran was my attempt to completely redo the Vim Fortran syntax package. But I don't think I ever finished it. The second one looks like what I've been using to modify the existing Vim Fortran syntax package.
Stefano Zaghi
@szaghi
@tomedunn Just tried both. Effectively the second seems works bettter, i.e. it enables syntax highlight for submodule/endmodule. However, I am not able to correctly fold module subroutine/end subroutine and module function/end function. Is it difficult to improve the folding? Anyhow thank you very much, now your vim.fortran is my preferred Fortran vim syntax :clap:
Tom Dunn
@tomedunn
@szaghi Glad it helps. Back when I put together the vim.modfortran package I put a good deal of effort into understanding how Vim syntax packages work but I never got very far. Compared to the syntax highlighting package I put together for the Atom text editor writing one for Vim is much more complex.
Stefano Zaghi
@szaghi
@tomedunn sad to learn this. I like Atom, but I am too much addicted to vim to use anything else...
Tom Dunn
@tomedunn
@szaghi yeah, I know what you mean. There is a pretty decent mod for Atom that gives basic Vim style keybindings but you still miss out a lot of helpful things. If you want to try to setup code folding for submodules you can find examples in the default Vim Fortran syntax file by searching for region.
Stefano Zaghi
@szaghi
@tomedunn Thanks a lot, I am not sure if I will find the time, but this information is a great help! :clap:
Stefano Zaghi
@szaghi
@tomedunn Dear Tom, I have just created a Pull Request for your vim.fortran. I have added the fortranModuleFunction and fortranModuleSubroutine regions for folding these constructs. I was unable to create a region for submodule/end submodule, the regex of vim is not intuitive at all! Indeed, I had few minutes to play with it, but the first saw vim regex really makes me afraid... The two folding regions addes seem to work, but feel free to discard my PR. Thank you again.
Tom Dunn
@tomedunn
@szaghi I added a region for folding submodules.
Stefano Zaghi
@szaghi
@tomedunn great! :clap:
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: