Piero Bosio Social Web Site Personale

@hattom that might explain it in the winter but not during other vacations. My very unscientific explanation is that they does it out of spite. Something like «oh so you want to build your career out of studying me? Well, you're going to WORK for it.»

People don't believe me when I say that volcanoes only erupt during vacations.

So anyway. Guess what me and my colleagues are doing right now.

#MtEtna #Etna #eruption #volcanology #remoteSensing #SEVIRI

The number of people who don't know about #GPUSPH within #INGV is too damn high (.jpg).

Memes aside, I've had several opportunities these days to talk with people both within the Osservatorio Etneo and other branches of the Institute, and most of them had no idea something like that was being developed within INGV.

On the one hand, this is understandable, especially for teams that have never had a direct need to even look for #CFD code because of the focus of their research.

On the other hand, this also shows that I should have been much more aggressive with marketing the project internally. (And don't even get me started on who had the actual managerial power to do so before me, but that would put me on a rant that I'd rather avoid for now.)

I'm glad I've finally started working on this aspect, but also I can't say I'm too happy about having to do so.

Hopefully this is something that will help bring mass to it.

This morning there was #snow on #MtEtna, yesterday there wasn't. I wonder when it happened.

#Etna #WinterIsComing

Today I introduced a much-needed feature to #GPUSPH.

Our code supports multi-GPU and even multi-node, so in general if you have a large simulation you'll want to distribute it over all your GPUs using our internal support for it.

However, in some cases, you need to run a battery of simulations and your problem size isn't large enough to justify the use of more than a couple of GPUs for each simulation.

In this case, rather than running the simulations in your set serially (one after the other) using all GPUs for each, you'll want to run them in parallel, potentially even each on a single GPUs.

The idea is to find the next avaialble (set of) GPU(s) and launch a simulation on them while there are still available sets, then wait until a “slot” frees up and start the new one(s) as slots get freed.

Until now, we've been doing this manually by partitioning the set of simulations to do and start them in different shells.

There is actually a very powerful tool to achieve this on the command, line, GNU Parallel. As with all powerful tools, however, this is somewhat cumbersome to configure to get the intended result. And after Doing It Right™ one must remember the invocation magic …

So today I found some time to write a wrapper around GNU Parallel that basically (1) enumerates the available GPUs and (2) appends the appropriate --device command-line option to the invocation of GPUSPH, based on the slot number.

#GPGPU #ParallelComputing #DistributedComputing #GNUParallel

I just discovered that apparently #Europass doesn't provide their .docx and .odt templates anymore. But they provide an #XML schema for the data in it, which is cool.

https://europass.europa.eu/system/files/2020-07/europass-xml-schema-doc-v3.4.0_0.pdf

seems to be the latest specification, although it's ridiculously difficult to find by “normal” means (a search from the europa.eu website itself, particularly the europass one).

The fact that this schema apparently has existend since 2013 and I only now find out is a bit grating, but then again whenever I've had to update my CV I've just been carrying over one .odt version to the next since I first got the template so …

Sulla strada per scendere al lavoro ci sono degli #stencil su un breve tratto di strada che porta anche ad una biblioteca. Oggi ho deciso di fotografare quelli testuali (altri sono impronte di scarpe e frecce), perché li ho trovati interessanti. Scusate se le foto sembrano fatte … con i piedi

#streetArt #arteDiStrada #aforismi