open TELEMAC-MASCARET The mathematically superior suite of solvers

Hi Everyone,

I have a request. I am expecting to have an internal discussion about Blue Kenue this coming Friday (10am EST 28 Feb 2025) with my management. This may result in an internal decision going forward.

If you (or someone you know) has used Blue Kenue within the last year (or so) and find it useful... now would be a great time to share with me why you find it useful, what kinds of impact Blue Kenue has on your operations/research/etc. and whether you believe Blue Kenue should continue to be supported and/or how you think it should be supported.

Please consider sharing your thoughts on this forum or sending your private thoughts to the contact email on the NRC Blue Kenue web page

All comments very welcome and appreciated!

Kindly... Alan

Hi Alan,

First, I would like to thank you for your great work on BK in the past years.

I will speak in the name of my compagny, ISL Ingénierie, in France.
We regularly use BK to generate meshes for TELEMAC 2D, 3D, TOMAWAC, ARTEMIS, GAIA models. And only for the generation part, boundary and initial conditions are set on FUDAA Prepro (old and unmaintained software but we have the habit), post-processing is also done on Fudaa Prepro or QGIS using PostTelemac plugin.

BK is the easiest software to install and use (in our opinion) to generate meshes for openTELEMAC environment. T3D Mesher is very powerful after all and easy/flexible to use compared to gmsh or other mesher.

This is pretty much all I can say as our use is limited compared to the full potential of BK.

Kind regards,

Hi Alan,

I think I will agree with Nico mainly, that BK is the easiest software to install and use that can do pre- and postprocessing with Telemac. In our group everyone involved with Telemac uses BK for some things. Also for students, we use BK as it is just very intuitive.

For meshing, I now mainly moved to triangle, and for spatial post processing I am moving more and more towards QGIS, but if it's about just taking a quick glance at the results or create simple meshes, BK is still my favorite program. And I think it is still the best tool for defining boundary conditions.

Kind regards
Frederik

My two cents ...

At my work, we typically use Aquaveo SMS to generate and improve the mesh, then export the *.2dm to Blue Kenue to generate *.cli and *.slf files. We do most of the preprocessing in SMS and most of the postprocessing in QGIS, as we find these programs more intuitive and easier to use than Blue Kenue, and more compatible with standard GIS file formats. Even then, because the newest publicly available version is 3.3.4 and this still has the apparent inability to write a double-precision .slf, this requires a coordinate shift, which renders it inconvenient. Most corporations do not want to install alpha and beta versions, so we are stuck with 3.3.4.

In all honesty, I would probably not use Blue Kenue, were it not for the step of generating *.cli and *.slf files. I find that the interface could be more intuitive, and there are plenty of small issues that I find frustrating. For instance, BK can only read rasters up to 24 bits, if my understanding is correct, whereas pretty much anything I use is 32 bits. I have never encounted this error anywhere else.

This is where I get controversial ... In my opinion, all of the hard work NRC is putting into CHyMS to basically create their own GIS platform could be redirected into adding features to QGIS, via a plugin or otherwise. QGIS can already interact with all sorts of geospatial data and read selafin files, and there are mesh generation plugins available. I think in the big picture, it would take less work to create a robust plugin than to try to untangle all of the years of legacy code in CHyMS, only to create a product that is similar to, but (in my opinion) less appealing than, QGIS. Again, this is not to disparage the hard work Alan and others are putting into CHyMS, because I appreciate the endeavours; all I'm saying is, the hard work could be redirected into an ultimately better product.

I hope this can help inform the discussion of CHyMS. Again, I'm grateful for the time you put into Blue Kenue, Alan - not the least how many times you've helped me understand bugs I've had - but in the big picture, I think it would be better for CHyMS to build onto quality, existing FOSS platforms like QGIS, rather than reinvent the wheel to support a relatively small user base.

Hope this helps,
André Renault

Excellent. Thank you for taking the time to share all of your opinions!

Please keep 'em coming! Controversial (or not) both are appreciated...

Kindly... Alan

On a second note, I might agree with André's take. In the beginning we used BK extensively, but whenever we notice that a step can be done in QGIS, we use QGIS, simply since it is a more powerful program in general. The step of converting .2dm-files to .slf and .cli files is really one of the only steps I still exclusively do in BK (mainly because I get some weird bugs, when I generate .slf files in python...).

Besides that, I still find the quick and dirty meshing of simple test cases quite intuitive and students can get a good grasp on BK using the tutorial Philippe Maron.

All that being said, the support for BK in this forum is still unmatched, as we can basically communicate with the developer directly and it is just overall a constructive atmosphere.

Kind regards
Frederik

Kind regards

Hi Alan,

as a long time user of BK I cannot resist not to answer you and the other forum answers.

In our company my collaborators and me have been using BK on a daily basis and in our view it is really a "Swiss Army knife" for pre and postprocessing of 2D numerical models, in comparison to other open source or commercial solutions out there (also the use for our own 2D FV model which is faster than TEL-2D FE )

Still I'm impressed about the compelling logic of the program structure, what the developers already 20 years ago or more had in mind. Starting with the open and efficient to use file formats, the various ways of easy manipulation of data, the logic behind the mesh generation.

We need in our daily industrial production not only mesh generation of some domain outline, but heavily need efficient procedures like mesh splitting, mesh merging, submesh handling, mapping / interpolation of various data (or parts of it) to other data, interoperability with other programs, etc. Furthermore, a lot of work goes always into the definition of some lines or polygons.... copy this part of a line, cut that portion of a line, etc. At least in our view for all these latter needs BK is the most efficient tool compared to other solutions, like QGIS.

We are still a bit sceptic about the QGIS hype which have been sorrounding us since some years. And we don't believe that in the near future there will be a breakthrough in QGIS related to 2D mesh handling (it needs a lot of money). Besides, that the processing tools for works as described above in QGIS are not available or their use needs xx more time than in BK, some other remarks: compatibility or even availability of QGIS plugins not guaranteed (happens sometimes e.g. when changing to a new QGIS version) or developer has to update the plugin with new QGIS versions. Even the underlying QGIS Python framework sometimes doesn't work with new QGIS versions. Shape file handling is standard in QGIS, ok, but such a lot of generated files... and I like more the i2s and i3s styles with immediate interoperability with text editors.

We use QGIS the other way around what other users reported: at the the beginning of a project or when new data comes, we use QGIS to convert all the data, which is not compatible to BK, to BK formats. Of course, like other said before e.g. for GeoTiffs this is sometimes amazing since BK doesn't support compression algorithms like deflate, still. So, may I continue with some personal suggestions for further developments, based on v3.3.4 (I have only a few and they overlap with other users): efficient visualization of meshes with more than 50x10^6 nodes, faster (parallel OpenMP?) mesh generation, handling of quadrilateral mesh elements, support of various formats of TIFF files (compression, bands, etc.), support of double precision slf, better mesh merging algorithm, fixing of some minor bugs.

Summarizing, in my view the basis of BK is really great and hence, it makes sense to develop BK further with the primary goal to enhance its efficiency in regards to the few points described above


Happy meeting!

Clemens