Re: FLUKA-VMC Interface discontinued (fwd)

From: Carminati Federico <Federico.Carminati_at_cern.ch>
Date: Fri, 26 Mar 2010 12:02:08 +0100

Dear Fluka Scientific Committee,
    thanks a lot for your message about fluka_VMC. We appreciate you and the FLUKA team taking the time to look in details into the VMC interface and making comments about it. We have read with attention the document you provided and we have a number of comments to it.

First of all you seem to assume that VMC aimed at offering access to all the FLUKA features. This is clearly a misunderstanding. We developed the VMC for the needs of the ALICE collaboration to be able to do full detector simulation with the FLUKA transport code. Therefore we only developed interface to the functionalities of FLUKA that were needed within this scope, without aiming at developing a full interface to all the FLUKA capabilities. Almost all the points you mention are therefore more "missing features" than shortcomings. These could be easily added if there was a request for them.

Furthermore you seem to assume that configuration via fluka_vmc AND native FLUKA cards for the same run is impossible. This is wrong. We are using a file input/coreFlukaVmc.inp in which we put the necessary FLUKA input cards which are not written automatically. It has a header and a trailer section. The cards automatically generated by the interface are put in between. Even if there is no "application programming interface" in the VMC code, additional header cards can be easily added. In this sense, the sentence "The user has therefore access only to a limited subset of the FLUKA physics and transport settings, ..." is factually wrong in most of the cases, if not all.

For "trailer cards" using material or region indices the situation is different. Here automatic writing would help a lot because of the handling of the indices. However, the automatically generated cards for material to region assignments and the material cards are fully documented and human readable. It would be in fact relatively easy to put additional cards by hand if needed.

For instance, the development of classes like TFlukaIon and TFlukaScoringOptions show that other areas of application can be easily supported in a modular way within the framework. There is no design flaw. It is just a matter of extending the existing code on a per-need basis. This was the philosophy of VMC all along, that we explained to you when you granted us the license. You have been aware of this since at least five years. Moreover, being the code open source and available, all this hardly can be said to come as a surprise to any of you.

As far as the last point is concerned ("There is evidence of several serious bugs and obsolete features in the interface"), it is commonplace in open source communities (and indeed in any scientific environment) not only to communicate the existence of shortcomings in your colleagues' work (e.g. programming bugs), but also to offer evidence for them. You have announced publicly already since several months that the VMC interface has serious bugs, but you never really told us what are these "serious bug". Without more information on your side we cannot judge whether we have something to fix or if you just misunderstood the functioning of the interface, as it is the case for most of your previous remarks. We would be very grateful if you could share (publicly if you prefer) your findings with us. In the process of implementing the interface we found also a couple of shortcomings in FLUKA and always showed a constructive attitude, communicating you immediately our findings.

We are glad that the we can continue using the interface, however let me remind you that this is currently impossible because we need a version of FLUKA compiled with gfortran and the -fPIC flags, as we communicated to you more than one year ago, and we are still waiting for that.

In view of the above, we will take no further action on this matter until either we receive a user requirement or we have more details from you on the (still mysterious) "serious bugs". Here follows a more detailed set of comments on your points:

1-13) False. The relevant cards can be added to the input, see above.

{In particular

11) This is off by default also in FLUKA.

12) This is for very specific applications (put recently for collimator design) and not needed by ALICE.

13) If you refer to Birks' law, then we leave this up to the user scoring routines, a question of design.
}

14) True by design, this is not a problem for our application.

15) This is supported via TGeo.

16,18) True by definition, we use a different geometry.

17) We never wanted to provide FLAIR functionality. All postprocessing tools can be used of course.

19) False, the relevant cards can be added to the input, see above.

20) This was done following you recommendation. A different value can easily be put in the input.

21-23) False. The relevant cards can be added to the input, see above.

24) Hitherto unsupported claim.

I trust you will forward this message to the fluka lists (fluka-users and fluka-discuss) in case they are moderated.

Best regards,

Federico Carminati
CERN-PH
1211 Geneva 23
Switzerland
Tel: +41 22 76 74959
Fax: +41 22 76 68505
Mobile: +41 76 487 4843

On 24 Mar 2010, at 17:19, Fluka Scientific Committee wrote:

> Dear FLUKA users,
>
>
> we regretfully have to announce that the use of the FLUKA-VMC interface is
> no longer permitted or supported, with the only exception of the Alice collaboration. Whichever further use of that interface will be considered
> an infringement to the FLUKA license. The main reasons for this unavoidable action are discussed in the attached document, which is the
> result of a careful examination of the interface carried out for the
> first time by the FLUKA developers.
>
> The Committee apologizes for having for so long overlooked the shortcomings
> of the FLUKA-VMC interface, thus allowing the spread of a tool that does
> not respond to the users' and the developers' expectations.
>
> All users/groups who were granted with the related license derogation will
> receive a dedicated communication.
>
>
> Cordially
>
> The FLUKA Scientific Committee
>
>

Received on Sun Mar 28 2010 - 23:46:03 CEST

This archive was generated by hypermail 2.2.0 : Sun Mar 28 2010 - 23:46:34 CEST