Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 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
  • Sep 18 19:07
    NicSAE opened #7
  • Aug 29 08:09
    ito436 opened #6
  • Jun 19 11:43

    szaghi on master

    Merge tag 'v0.0.7' into develop… Merge branch 'master' into deve… Merge tag 'v0.0.8' into develop… and 3 more (compare)

  • May 28 14:57

    szaghi on master

    update submodules (compare)

Izaak "Zaak" Beekman
@zbeekman
@szaghi We have an in house Finite Difference DNS/LES solver for Turbulence research of compressible flows. (BLs, SW/BL interactions, Shock-isotropic-turbulence interaction, etc.) My one comment about original Jiang & Shu WENO is that it is quite dissipative. You can play some tricks to get it to behave more like a Padé scheme, at least in the context of Finite Difference
Chris MacMackin
@cmacmackin
Thanks @zbeekman ! I've recreated the repository there and would request anyone who wants to look at it follow this link: https://github.com/Fortran-FOSS-Programmers/FLATPack. The old repository hosted on my own account will be converted to my personal fork.
I guess the other option for the language to implement this in would be shell-script. Personally, I wouldn't be a great fan of that because I don't have much experience with shell scripting and find it ungainly compared to working in a good scripting language like Python. However, more people might know it and it does have the advantage of being able to interact more easily with the system.
Izaak "Zaak" Beekman
@zbeekman
I know bash quite well, but from what I’ve seen of Python, it seems to be able to have more fine grained control across OSes and will provide a more unified, coherent and polished system/interface than shell script could. One of the first things such a project will require is some convention for installation that will allow multiple versions of libraries etc. to peacefully coexist along side each other.
@cmacmackin we should probably create a separate gitter.im room for FLATPack since I anticipate there being quite a bit of discussion about it… that way we can keep this space for more general announcements
Chris MacMackin
@cmacmackin
Fine with me!
Izaak "Zaak" Beekman
@zbeekman
for anyone who wants to provide suggestions/advice/input on FLATPack, you can head to this room: https://gitter.im/Fortran-FOSS-Programmers/FLATPack
Stefano Zaghi
@szaghi
@zbeekman Some my posts of yeasterday were missed. I replay now: you are right, the standard Jiang&Shu could be too dissipative. I follow the research of Pirozzoli (teaches in my old University, sad to say I am old...) and I know that hybrid-compact-schemes can gain Padé-like accuracy. However, the coefficients tuning for some specific turbulence problems (in general the algorithms tuning...) not fully convince me on its generality. However, we will surely discuss in more details elsewhere :-)
Izaak "Zaak" Beekman
@zbeekman
@szaghi sure, shoot me an email if you like… The paper I referenced doesn’t tune coefficients for specific turbulence, it adds a fully downwind stencil to the candidate stencils and changes all of the coefficients using the extra DoF added by the new stencil to bandwidth optimize the spatial discretization while maintaining the same order of accuracy.
Chris MacMackin
@cmacmackin
Sorry to post about this twice in less than a week's time, but I have release another version of FORD. This release sees a few changes to some of the default behaviour and thus is considered a major release. That should be it for FORD for a little while now--I'm hoping to focus more on FLATPack.
Stefano Zaghi
@szaghi
@cmacmackin : you have not to be worry, I almost sure that the whole group is interested to FORD progression as me. Please, let us know of any new release (indeed, I already track you!). Moreover, I suggest to create a new group repository shere save a list of group-awesome-projects with a section of awesome-group-members-projects, on the same guidelines of awesome-fortran, but specific of our group-members. Maybe, it could be just a page of group-homepage. What do you think about this?
Stefano Zaghi
@szaghi
Dear all, I have done some (little) progress on XML parser. Now it has a minimal functionality.
Stefano Zaghi
@szaghi
Hi all, I have just created a new team dedicated to the XML parser. Who is interested to collaborate send me a :+1 and I will add him to the team.
Michel Müller
@muellermichel
I really like the idea with FLATpack - I think my work could profit quite a lot from such a solution. It would make it so that I could modularize the Hybrid Fortran installation. One example would be the different implementations I have for the backend - currently OpenACC, CUDA Fortran, OpenMP, plus some tracer/debugger implementations that inherit from the base ones. I'm wondering: Would preprocessing / static analysis tools also be part of the scope for the payloads, or only Fortran tools/applications themselves?
Chris MacMackin
@cmacmackin

@muellermichel Thanks for your interest! At present, these sort of details haven't been decided. I hadn't initially envisioned anything other than Fortran software, but I'm open to discussion. You can join to FLATPack discussion to talk about these things.

One issue which I can foresee with a tool such as Hybrid Fortran is that (as far as I can tell from a brief glance at the code) it relies on various Python packages and FLATPack would not be designed to process those dependencies. It seems to me that it might be better to place the HybridFortran code itself on PyPI and then place examples in FLATPack. I generally think that it is better to place a project in the package manager for the language it was written in, as this is better suited to handling its dependencies.

Izaak "Zaak" Beekman
@zbeekman
@szaghi want to make a room for FLAP and I can help you with your git woes there?
Stefano Zaghi
@szaghi
done
Stefano Zaghi
@szaghi
Hi all, I just see that D. Rouson joined Github... I have invited him to our group immediatly! Maybe a miracle could happen and he accept... his experience is great! For example he develop opencoarrays...
Stefano Zaghi
@szaghi
@kmanalo can give us more details about fortlua? It seems interesting but I do not completely understand aims/tipical-usage/development-status/todo/doc...
Tom Dunn
@tomedunn
Hi everyone. I'd be interested in contributing to some Fortran projects. So I'll be looking around for something to help with. As for my own projects, I've put together Fortran syntax highlighting packages for atom and for Visual Code. Are their any other editors that people use which could use a good Fortran syntax highlighter? The Atom syntax highlighter should be easy to port over to Textmate and Sublime but I haven't had much motivation to do that since I don't actually use them as daily drivers.
Kevin Manalo
@kmanalo
@szaghi Hi only just saw the ping now. The idea behind FortLua (guided by a workshop given by Cornell for using HPC resources on TACC) was to extend the benefits of embedding Lua inside of Fortran. The reason why Lua was considered is because the environment modules system in use in the workshop HPC system is Lmod developed by R. McLay at TACC. Also, Because Lua's footprint is so small, it's basically included with the project. You can create functions inside of a Lua configuration file (and thus no re-compiling). One way that I'm using this is to leverage a GNUplot API from a Lua library, so that the creation of a 2D scatter plot is more seamless - as I did not want to create a two-step process of writing to disk and using a shell script to run GNUplot. Also, for all those needing test projects for package management systems feel free to modify. The Makefile is simple enough but requires Lua library specifications. Needs more testing (only really fully checked with Intel and Lua on Linux). Should work with gfortran and lua on Mac, and Windows integration would also need some testing. Probably all needs to fit under a build testing harness.
Stefano Zaghi
@szaghi
@kmanalo Thank you for the explanation. I'll watch it, I have not really the time to test it, but it seems interesting. Thanks for sharing it
@tomedunn Thank you for the help. I am using VIM: its syntax highlighter is good, but maybe your is better. Can you port your syntax to VIM? Atom is interesting, but I am so addicted to VIM that is difficult to switch off...
Tom Dunn
@tomedunn
@szaghi I actually use Vim as my daily driver as well. I do most of my coding remotely on Linux servers and Vim via terminal SSH is just too convenient. I have a number of tweeks to Vim's Fortran grammar but I've been meaning to do a more focused effort on incorpating more modern Fortran constructs.
Stefano Zaghi
@szaghi
@tomedunn :+1:
Izaak "Zaak" Beekman
@zbeekman
FORD is now available through Homebrew, for those of you using Mac OS X: brew update && brew install FORD
Also I’ve finally settled on a webpage template: Lanyon Jekyll template and will be trying to add some meaningful content sometime soonish
Stefano Zaghi
@szaghi
@zbeekman great! I have some days very busy at home, I hope I will contribute monday.
@tomedunn how difficult is to extend a vim syntax highligthing? I am using a personal flavored markdown syntax and I would like to have vim correctly highligth and fold my flavored markdown... can you help me? where I can start? Currently, I think I am using the Tpope syntax.
Tom Dunn
@tomedunn
@szaghi I haven't taken too deep a look into the Vim syntax engine yet. So I don't know how hard it is to do more complicated alterations like changing indenting and code folding. However for doing simple keyword highlighting it seems pretty straight forward. I've created a repository vim.fortran that I'm planning on building the Vim syntax package in. At the moment it contains a single file that I have in my local .vim folder containing a handful of simple fixes. If you want a larger example you can find the full fortran.vim file in your Vim install folder. I don't understand all of it but you can figure out a good deal by just hacking around in it. I'm planning on putting in some serious time on this after the weekend.
Stefano Zaghi
@szaghi
@tomedunn thanks! I will start from your vim.fortran!
Chris MacMackin
@cmacmackin
Just announcing that there is another release of FORD. There are a few changes which are not backwards compatible, although they are unlikely to cause anyone any problems. There are some new features which people might find useful. See the ChangeLog.
Izaak "Zaak" Beekman
@zbeekman
Thanks Chris! I'm going to submit the formula update to homebrew tomorrow.
Izaak "Zaak" Beekman
@zbeekman
FORD 4.0.0 now available through Homebrew
Chris MacMackin
@cmacmackin
I've just released a small bugfix to FORD. @zbeekman, you may want to update the Homebrew formula again.
Stefano Zaghi
@szaghi

Dear All, I would like to highlight that I have just created a new Group repository, i.e. https://github.com/Fortran-FOSS-Programmers/WenOOF

As I said some days ago, I am interested in developing a Fortran library aimed at WENO interpolation. I added some of you to the team I have created for the project because I guess they should be interested, however I hope that many others (all...) will join.

I plan to pollute the project with some of my old weno codes, but feel free to stop me when you want.

The readme should explain my desiderata, however the project is very free and we can discuss how change goals, how implement them and all other related stuff. Some of you already told me (via PM) that the name is orrible... feel free to change also the name :-)

See you soon.

Izaak "Zaak" Beekman
@zbeekman
@szaghi: WenOOF looks interesting. I’m wondering however, if it is of general enough utility to be part of Fortran-FOSS-Programmers? My original idea was to focus more on projects that could be more useful to ALL fortran programs. Things like JSON libraries, YAML libraries, Fortran interfaces to common C/C++ libraries, Fortran command line parsing, Fortran package managers etc… What do you and others think? Should we limit Fortran-FOSS-Programmers to this more general type of software, or does it make sense to also add more niche packages like WenOOF? I’m happy to consider both options. If we decide WenOOF should move, we could always create a separate organization for that.
Milan Curcic
@milancurcic
I personally don't see a good reason to limit the group to general use projects only. Niche (domain specific) packages will be useful to only some people, but they don't get in the way of anything else.
One question I have for @szaghi is: Did you do a research on what existing WENO open source exists is out there? Did you consider extending existing frameworks/solvers like Clawpack (https://github.com/clawpack/clawpack )? Is there a big need or demand for a dedicated WENO-centric framework?
Giacomo Rossi
@giacombum
I totally agree with @milancurcic: if the name of the group is 'fortran FOSS programmers' I think that this group should include all free and open source fortran projects, not only projects that can be useful to ALL fortran programs, imho
Izaak "Zaak" Beekman
@zbeekman
Great, I’m open to the concept, just wanted to gather other opinions
Stefano Zaghi
@szaghi

@milancurcic, I am sorry for my delay.

I know clawpack and in particular I studied the work of Prof. LeVeque (and his great book, I invited him to join our group without success), however I do not like the development-way of clawpack & co. (amrclawpack): it is not OOP, it is not moderm (many .f not modularized, old-fashioned style) and it is quite monolitic (at least basing on my memory, it is passed sometimes from my last checking).

After some years of work, I have built-up the preference to small libraries being tailored to perform a reduced set of tasks, but doing these at the best (reusable, modular, well documented, etc...). Clawpack is great, but it is not what I want.

As the weno is concerned, I don't care how many people need it, I just want it and thus I like to share with the community: probably the demand for a weno-library is limited to me and maybe zaak, but this is not a matter for me (maybe later day I will start a project being totally usefulness :-) ). Each time I start to writing a code I check if there is an existing one in order to avoid to reinvent the wheel: for WENO I find a nice project in Python, but no one in Fortran satisfying my desiderata. Obviously, my search could be incomplete and if you can point out nice project I will very happy to study/use it. In particular, clawpack is not a WENO interpolations library, but a solver for PDEs system of conservation laws.

Maybe, you do not like I started the project into the group framework, but I supposed that this was the spirit of the group: start each project we care about hoping that other members will be interested on, but do not limit yourself I you will be alone. Indeed, I hope that all you open a lot of new projects soon, beacuse I am very interested to learn many other things that are outside from my experience. Anyhow, if I am misleading the group aims, I apologize myself.

I do not follow your and @giacombum points: what you are suggesting? @giacombum seems to promote the group should inglobate ALL fortran projects, that should include also a project like Wenoof that have just one interested member, on the contrary it seems (due to my bad English undestanding, probably) that you are promoting only projects that many members want, and this should exclude Wenoof. Maybe, you want that the group starts a discussion before open a new project?

I vote for a free starting approach: all member should be allowed to start a new project, then, if the group votes that this project does not satisfy the group roles (aims, ethics, interests... I will try to add some hints into the group's mission page) simply remove the project from the group umbrella and leave it only under the member's personal benhalf. The reasons I like this approach are:

  • we are linked by Fortran, but we have very different interests and backgrounds; this has pros and cons:
    • our diversity is very exciting (at least for me) because it is a great chance to learn many intersting new things;
    • due to our diversity, it will be difficult to find a project that the whole group is interested on (may FLATPack will be the only one, it being very Fortran centric);

These are my opinions, I hope to be on topic.

Oooops... I am sorry I was too lenghty!

Stefano Zaghi
@szaghi
As I guess, I read wrong all your messagges (and missed a lot... I was not at office in the last days) and I just see that is Zaak (and maybe Milan) to not feel good with my approach. I am sorry for my mistake. Anyhow, my opions are general and not related to someone rather to a concept.
thank to the young @giacombum for showing my errors :-)
Giacomo Rossi
@giacombum
I'm always very very attentive with old people, dear @szaghi :-)
Izaak "Zaak" Beekman
@zbeekman
@szaghi I just wanted to gather some more opinions on the types of projects that we include here. I support the idea of an open, inclusive community And the addition of niche projects after reading @milancurcic 's comment.
Stefano Zaghi
@szaghi
Sure, I am sorry, but I have missed a lot of previous messages. Anyhow, I vote for open-and-enventully-purge approach as above described :-)
Milan Curcic
@milancurcic
@szaghi Thank you for your thorough response, all looks good! :thumbsup:
To reiterate, I am for including any Fortran project under the FOSS group, be it very general or very specific. Hope this is more clear :)
Stefano Zaghi
@szaghi
@milancurcic Thank you Milan, now it is clear also for me :-) I am sorry for my mistake! Maybe, before the middle of August I will promote a very usefullness fortran project to the group... stay connected!