szaghi on master
Merge tag 'v0.0.1' into develop… Fix paginate issue With the ne… Merge branch 'master' into feat… and 7 more (compare)
szaghi on master
Add Euler 1D solver app Add Eu… Merge branch 'master' of github… (compare)
milancurcic on master
fix typo in readme Merge pull request #39 from let… (compare)
szaghi on master
Merge tag 'v0.1.0' into develop… Merge branch 'master' into deve… Merge branch 'master' into deve… and 1 more (compare)
szaghi on master
update submodule (compare)
szaghi on master
update submodules (compare)
Good Practice
discussion!
To whom it may concern,
I have released a library for string handling that should condensate many of your facilities into one, single, OO-designed class:
https://github.com/szaghi/StringiFor
It exposes only one type, string
, and it already has many methods inspired by other, more rich, languages (Python, obviously). However, the library can be considered not fully stable, but almost stable.
The documentation is still poor, but almost all should be already clear.
I will adopt it intensively in the near feature (FoXy, FLAP, FOODIE, others).
Your suggestions are, as always, very welcome.
My best regards.
New features:
Bug fixes:
\g
in character literal no longer causes crash (Issue #136)concurrent
in do concurrent
as function call (Issue #131)::
now accepted in all use
statements (Issue #120, PR #123)deferred
now included in lists of type-bound procedure attributes~
(Part of issue #134)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!
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!
select type
statements.
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.
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.
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!
@giacombum pointed out this interesing project
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.
optional
arguments, but it seems too bad also for me :-)
@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:
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.
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
@/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:
submodule
and endsubmodule
;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
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:
region
.
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.
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.
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.
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.