Hi Zach, > I don't love the idea of picking at random a process to run; Our code is actually designed at multiple place to configure itself at the time of the first process/loading of the code. Such behaviour is actually especially useful when combine with the auto-update feature of MG5aMC (feature that you do not use). This is perfectly fine in general but in the case of filesystem without write disk access since the code can not configure itself in that case. This force you/us to find some work-around from each of the auto-configure step in order to have those working with your setup. (Copy-file, modifying configuration file,…) I think that running one LO and one NLO process (you do not need to run them, just to “output” them) is actually the best way to handle such difficulty in the long term. But this is obviously your call if you prefer to catch those problems one by one at each new release. By the way, do you use the script compile.py? If yes, one correct solution would be that I run one LO and NLO generation from that script (and then clean the associate output obviously). > Could you confirm that > these are the right ones to cover most LO and NLO use cases? > install SysCalc Golem95 PJFry QCDLoop maddm collier ninja oneloop I do not know which of those library " Golem95 PJFry QCDLoop collier ninja oneloop” are compatible with your “set dependencies “ options. Valentin will give more details on that. Concerning SysCalc, we have now an internal python module handling the same functionalities (and more like you can change the dynamical scale definition). Since the user support for SysCalc is not that great, I would suggest to use that one instead. It only requires to have lhapdf6 with python integration activated. Additionally, Cuttools and iregi needs to be compile (we do not have any install for such tools which are automatically compiled when you “output” your first process with loop matrix-element. > I suppose the first point that you raised indicates that the default > path in the config file points to a path that doesn't exist. Correct that path point to the default position where that program is expected to be installed. In most of the case this is therefore not valid > Why > wouldn't the default be set to none, and only if the user chooses to > install one of these externals would the default config card be changed > to use that location? Actually we use the fact that the “ninja” path is not valid to trigger the question on which reduction tools. If the user specify that he did not want to install ninja then this path is set to None such that we do not ask the question again. I can obviously prevent the asking of such question if I’m not in a write system. But in this context this does not sounds a good idea. Cheers, Olivier > On 18 Feb 2017, at 04:40, Zachary Marshall