Home
The pbl_met is a collection of Fortran modules dealing with various aspects of micro-meteorology, designed to support the construction of meteorological processors and data analysis codes in context ranging from pollutant dispersion modelling to ecosystems ecology.
Short description of pbl_met
What is it?
pbl_met is a library composed by various Fortran modules, test programs and accompanying data. The purpose of pbl_met is to alleviate the chore of writing meteorological processors and data processing systems, by providing routines computing or estimating the quantities commonly required by atmospheric dispersion models and other computing codes.
Why open source?
By its very nature, the pbl_met plays a foundational role in open source and commercial applications (for example the SODAR-aware meteorological processor and atmospheric dispersion input preparation code ST-Me by Servizi Territorio srl).
Because of this foundational role, it is important its structure and implementation details are accessible to everyone for inspection, correction and extension. This can happen if the pbl_met code is open source, and people actually access and peruse it.
Library organization
pbl_met is delivered as a set of Fortran modules, each dedicated to a specific theme in met processing (e.g. psychrometry, radiation, PBL, ...).
Individual modules are interdependent, and then it is advisable to always download the whole library.
In this Wiki individual modules are also shortly described: check index to discover all about them. Also please consider pbl_met has been intentionally designed for source readability: sources themselves are the eventual documentation. pbl_met is open source, so please consider exploiting this nice opportunity.
Fortran version and reference compilers
Modules are written in Fortran 2003 with a minor use of 2008 extensions. Most pbl_met modules however comply with the simpler Fortran 95.
pbl_met has been designed to be compiled using the GNU Fortran Compiler, gfortran. Compilation has been tested from gfortran version 4.4 and following. If you use an older version we recommend you upgrade your compiler.
Also notice the authors and maintainers of pbl_met will make no specific effort to held code compatible with verson 4.4 of gfortran - nor to make specific effortsto breach it intentonally, to the extent possible. That said, we would like to reassure you about the fact pbl_met has a relatively simple structure, being mostly composed by neat functions with ew defined inputs and, in most case, a unique output.
Support of compilers other than gfortran
In addition to the GNU Fortran, we support use of the Intel Fortran Compiler. The community edition of it has been used in Linux for this open-source project.
Some of the authors have successfully built pbl_met with compilers from other developers/vendors. Our current impression is pbl_met is quite compiler independent, but our tight time frame did not allow for a systematic test. By the way, this is an interesting volunteering area.
License
pbl_met is released under LGPL v3.0.
As such, it may be freely incorporated in both open and closed source codes without a need for explicit endorsement by Servizi Territorio srl. If you have not already done, we advise you to check carefully at GNU Foundation site to discover any restriction which applies.
We'll be glad to get from you, in case you employ pbl_met, to let us know. We'd also appreciate your citation, in case you have used pbl_met to process data for a document to be published somewhere (including of course papers on peer-reviewed journals).
Intended use of modules
We, the authors, include pbl_met modules directly in our projects, whenever we need them, directly in source form.
Unlike in the old PBL_MET, we have intentionally and positively decided to not package pbl_met as anobject library.
We feel using sources directly, rather than linking to a pre-canned object library, encourages curiosity: meteorological processing is quite an art more than science, and a critical mind set is essential to produce intellectually honest and professionally sound results. This is an easy catch given pbl_met structural simplicity - really, building a library seemed us overkill.
Of course you are free to package together pbl_met modules as an object library if you like. We too have made from time to time. Using sources directly instead of compiled object code is quite the norm in communities like Ada language users, as a way to encourage code understanding - something of great value in safety-critical applications. The same is maybe not yet so common among Fortran programmers, but we would like you too give this way a try.
Coding style
We've choosen to privilege readability and understandability over extreme code optimization. After all, what we consider "processing a huge mass of meteorological data" means dealing with thousands, or tens of thousands, maybe a million data records: an almost-nothing by today computing standards. The meaning of "efficiency" is really not the same it was some years ago.
On the other side, some of the meteorological data processing or estimation is quite intricate, and not always consensus has set over one method or the other. So, being able to understand what is going on behind the hood may be welcome.
By reading the sources, you may get an impression of a "high-oxytocin-low-steroid" place. That is. Maybe, gathering something orderly and useful from a mess of data is a task more eliciting the yin rather than the yang side.
Nevertheless, the fact this task occurs most often invisibly to final users does not means it is extremely fascinating on one side, but also in the meanwhile, extraordinarily dangerous if done haphazardly and without placing love and responsibility in the process.
More specifically, we have done our best to clarify our intentions about routine argument use, formulae, and so on. We intentionally have used long, meaningful names (unless some internationally known symbol is in wide use to mean the same thing). We've employed extensively the syntax features allowed by Fortran 95 and following to produce clear code, with some (sparingly) use of newer Fortran 2003 and 2008 constructs, where useful.
From time to time we had to use some "applied-math stuff" like solving equations iteratively, or finding solutions to ordinary differential equations, and so on: whenever possible we included the due code directly in the modules using them, as internal routines,so you may easily figure out what is happening.
We understand Fortran modules, used carelessly, may make their users life miserable (either by a horrible mess of overlapping names, or the even worse prefixing used to avoid them. To prevent thistrouble source we defined the default visibility of module symbols PRIVATE, thus exporting the very few important as PUBLIC. This will help you with name overlaps.
A systematic use of IMPLICIT NONE statement has also been used. By so doing we actually constrict ourselves to declare all variables, a very healthy habit some old-style-high-steroid FORTRAN programmer might not completely appreciate. We apologise to them all - but acknowledge the priority is in delivering code which is correct, or (better even) may be proven to be.
We made our best to write code you can understand (possibly, with a bit of study and application - the subject is intrinsically quite advanced physics - say, not the type you find in high school). But we can't ensure having made all things "ideally". Sorry so sloppy. If in case, anyway, please do not hesitate to contact us - our e-mail-office-door is tendentially open (if we do not respond within a bunch of nanosecond, please consider the possibility we're wandering around the little pearly Schwartzsee snorkeling around the seaside, or going take our cubs at school, or any other human type of activity: just be patient, we'll come; and if you are really interested in getting the solution worked at, please document as throughly as possibly your discovery or necessity, and file an "issue" on the Github repository - easy task).
History
The actual pb_met has originally been developed by Servizi Territorio srl under the name PBL_MET by the pioneering effort of Roberto Sozzi and Daniele Fraternali, and used there internally until currently in their consultancy activities.
The first version of PBL_MET has also been presented at the 2nd Workshop on Harmonisation within Atmospheric Dispersion Modelling for Regulatory Purposes, held in Manno (Switzerland) in 1993.
For a time, PBL_MET has been also sold as a software product by Servizi Territorio srl.
The original contributors were Daniele Fraternali and Roberto Sozzi. Their version is still retained, for completeness and historical fidelity. Besides, our gratitude to them and their work - and to the various nameless people who from time to time contribute to the "old" code.
For user convenience we have also placed the old PBL_MET in directory "PBL_MET_old" on GitHub source repository: that was our starting point, and to some extent it may still be useful. But please, consider its interest today is mainly historical. With time, more and more of it will be replaced by more up-to-date routines, placed in other repository directories.
Old PBL_MET users will discover the scope of the new pbl_met has expanded somewhat. In addition to Planetary Boundary Layer related routines, now a directory dealing with "instrumentation" has appeared. This was an inevitable consequence of the technical evolution in the field, no less quick than in any other.
And now...
Since then the library has been expanded, revised and tested to the extent possible. In 2015, a task has been undercome by Servizi Territorio srl to place the current version of PBL_MET, now named pbl_met, in the open-source universe, as a mean of sharing knowledge and, yes, as a capability demonstrator (Servizi Territorio srl wins part of her bread by running atmospheric dispersion models, an activity demanding massive meteorological data quality assurance and processing).