Hi Khoa, yes, it's always better to create nodes on the heap instead of the stack (i.e. with new). Therefore, you should use a SAMSON pointer (SBPointer) to hold it and destroy the node automatically when the variable gets out of scope.
@Andrii It can be done from the code. For now, we do not have docs/help web-pages for each of the SAMSON Elements, but it is in our plans to have them generated automatically for the exposed functionality.
To get UUID and the class name of an Element from which you want to use functionality, you can open the Log (Edit menu -> Show log), then you can search for the Element and check its UUID and the class name:
Now, in your code, you can do the following to print the exposed functionality of the Element:
// Create a class proxy
SBProxy* classProxy = SAMSON::getProxy("PDBDownload", SBUUID("6F5D45C5-E76E-CDC8-52D5-D2821C128BE8"));
// Print class constructors
// Prints the interface
It will print the exposed functionality (constructor factory, interface functions, attributes) in the terminal (std::cout stream), like this:
You might need to allow the terminal with "--logconsole" flag when running SAMSON.
If you have some problems with std::cout not printing to your terminal, you might print it yourself into std::cerr:
// Print interface
std::cerr << "Interface:\n";
auto functionMap = classProxy->getInterface()->getFunctionMap();
for (auto i = functionMap.begin(); i != functionMap.end(); ++i)
std::cerr << i->getKey() << "\n";
// Print attributes
std::cerr << "Attributes:\n";
auto attributeMap = classProxy->getInterface()->getAttributeMap();
for (auto i = attributeMap.begin(); i != attributeMap.end(); ++i)
std::cerr << i->getKey() << "\n";
I thought I'd clarify what's going on with Brenner and ASED-MO. While SAMSON and numerous SAMSON Elements are and will remain free forever, both for academia and industry, some SAMSON Elements will now have a commercial license (for industry and / or academia).
In effect, SAMSON Connect is becoming a marketplace for molecular modeling, where developers have the possibility to integrate and commercialize their tools (think App store for molecular modeling, except everything is integrated into a single, universal platform which makes it possible to combine modules together and gives new possibilities). Our goal is to contribute to the development of an integrated ecosystem for molecular modeling, where users can install tools in a few clicks, have them all integrated in the same platform, are able to combine them, pipeline them, etc. Since SAMSON has an open architecture, and the SAMSON API makes it possible for anyone to integrate existing tools, create new ones from scratch, develop new force fields, create new visualizations, etc., you can imagine the huge possibilities the SAMSON model gives.
As with other marketplaces (iOS, Android, etc.), many SAMSON Elements are and will continue to be free, and new free SAMSON Elements will continue to be published. However, our goal with this hybrid economic model is to reach the best of both worlds: serve the molecular modeling community while supporting the development of the best possible platform.
In the 1st case, you have more functionality and control over processes. The 2nd one is faster to develop and try, and you can further use the developed scripts for your tasks.
For the simulation in which you are interested in, you can use GROMACS Wizard Element (see the GROMACS Wizard tutorial), which allows you to easily run simulations using GROMACS (it comes with the Element) including various temperature ranges. There is yet no possibility to run simulations automatically, but you can launch many simulations in a queue using jobs. In future releases, it will be possible to run them on the cloud. You can freely try this Element for 30-days.
The size of the system for simulation is limited by your computer performance (RAM, CPU, GPU) and the max computation time you are willing to spend. In SAMSON it is possible to load systems with tens of thousands of atoms (depending on the performance of your computer).