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)
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.
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).
This is a major release and thus has some non-backwards compatible changes, although every effort has been made to keep them minor.
project_dir
option in the project file is now src_dir
proc_internals: true
in the project file.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:
fixed_extensions
can now be processed (using the fixed2free tool by ylikx)block data
(Issue #147) and common
features are now supported${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)@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
(or -I
) flag at the command line (Issue #143)Bug Fixes and Miscellaneous:
use
d in modulesDear 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.
@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:
@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
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
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.
My dear Fortranners, I just posted a question on SO that has been bugging me on and off for few days now:
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.
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)
@/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?