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)
szaghi on master
update submodules (compare)
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?
@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
andme+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?
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...
@/all @jacobwilliams
Dear all,
I am now approaching to implement some interpolation procedures for some different purposes:
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
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:
@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:
Cons:
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.
@zbeekman Giacomo used a kinda of multi-grid (non dynamic/adaptive grid refinement), I am using dynamic overlapping grid (Chimera) with also multi-grid acceleration, but the point is that we want to have:
One crucial point (among others) is doing interpolation with very different solutions computed on the some region.