FAQ¶
Can the GUI in AMS2020 read older inputs (.adf) and results (.t21, .*kf)?¶
The GUI will try to convert old .adf files to new .ams files as best as it can.
We attempt to keep the 2020 GUI version as much backwards compatible as possible for visualizing results such as spectra, orbitals, band structures, trajectories etc. from older .t21 and .*kf files.
Please let us know at support@scm.com with your old input / result files if it doesn’t work for you.
Which hardware should I get?¶
In general, the best hardware will be: the latest generation of processors, 4GB RAM per core and an SSD. See also the summary of a hardware FAQ session from October 2020. For the latest information, see this installation manual.
Based on your budget, an older processor, 2GB of RAM per core and a standard hard drive may also be sufficient for running ADF jobs. Since floating-point performance is crucial for ADF, we do not recommend to use hyperthreading or use all Opteron logical cores (i.e. run one process per floating point unit). Note that since chips are continuously improved, specific recommendations may change. As of mid-2017, these configurations should give the best performance for ADF:
Desktop or laptop: an Intel i7 processor from the latest generation, 16GB of RAM or more, and an SSD (a fusion drive may also work).
High-end workstation or a cluster: a dual-CPU Xeon SP setup with at least 2GB, but better 4GB, of RAM per core and an SSD. Using an SSD becomes more essential as the number of cores per node increases. For calculations on multiple nodes, get a fast interconnect (Infiniband).
Update mid-2019: Rome, the latest Zen 2 AMD architecture (Epyc, 3rd generation Ryzen), give very good performance for ADF. 4GB RAM per core and SSD are still recommended. Make sure you download the Linux binaries optimized for AMD Zen.
Similar requirements should hold for BAND (maybe you can benefit from even more disk space) and ReaxFF (less memory intensive than ADF).
I receive this error on my Apple Silicon mac: Illegal Instruction 4¶
Illegal Instruction: 4 indicates an illegal CPU instruction. You have probably installed the wrong architecture version of AMS.
The x86_64 intel version of AMS should not be used on Apple Silicon machines (M1, M2, M3), which have arm64 architecture. For macOS users we provide a native version for arm64 architectures that is much faster and should not produce such errors.
Please take the following steps to ensure proper functioning of AMS:
Delete the old x86 Application (drag it to the bin).
Delete the folder
/Users/username/Library/Application Support/SCMwhich may contain x86 packages from the old installation.Install the version labeled Apple Silicon from our downloads page.
I can not open the ADF / AMS app on MacOS Catalina¶
If you open AMS for the first time from your applications, you’ll see a notice “AMS20xx.xxx” can’t be opened because Apple cannot check it for malicious software. To fix this:
In the Finder on your Mac, locate the app you want to open.
Control-click the app icon, then choose Open from the shortcut menu.
Click Open.
The app is saved as an exception, and you can open it in the future by double-clicking it or from your Applications on the Dock.
I only have OpenGL 1.x on my computer. Can I still use AMS?¶
Yes! From on AMS2019.304 you can use software rendering instead. To activate the software rendering, type the following command in your command line before starting the GUI:
export SCM_OPENGL_SOFTWARE=1
To make this permanent, just add it to your $HOME/.bashrc file.
Note: This option replaces the former
export SCM_OPENGL1_FALLBACK=1
Users with older versions can still make use of the old – less efficient – OpenGL 1.4 fallback option, as described for AMS2019/18 or ADF2017.
Please contact support@scm.com if none of the above solves the issue.
My ADF inputs and scripts no longer work with AMS2018? And AMS2020?¶
In AMS2020 a major overhaul of the input for ADF has been made, unifying inputs more strongly across modules in the suite.
With the restructuring of our code base and introduction of the AMS driver we have rewritten the input handling to improve cross-engine compatibility.
In most cases, the GUI will have backwards compatibility. And so will amsprep and amsreport scripting tools. However, if you use command line input files and home-grown scripts, you will find that unfortunately these will no longer work with our 2018 version.
How can I script with python or use command line tools on Windows or MacOS?¶
Starting with AMS2018, just click help -> Command-line (Windows) or Terminal (MacOS) in any GUI window to start a terminal with all the environment variables set properly.
2017 and earlier versions On Windows, use the adf_command_line.bat tool to open up a command line with the ADF environment set up. You can use ‘sh’ to run a shell command or by itself to open a rudimentary shell.
On a Mac open a terminal and type a dot. Then open a GUI and go to Help: Show AMSHOME in Finder in the menu, drag that to the terminal and press enter (see also video).
Will the integrated GUI work as an interface to all my SCM products?¶
Yes, the integrated GUI works with all our software as well as with MOPAC and Quantum ESPRESSO for which also provide binaries.
I can’t see special characters in the GUI?¶
The GUI used unicode characters in many places. For example, the proper characters for Angstrom, degrees Celsius, and many more. You can see examples by starting AMSinput, selecting a Geometry Optimization, and then going to the details page (by clicking the … button). There you should see a couple of Angstrom symbols if everything is working as intended.
On most machines this will just work out of the box. If not, the issue might be that the default font on the machine does not support such characters. Try installing a font line DejaVU Sans and Monospace DejaVu. On CentOS you can do this (as root) with the command:
yum install dejavu-sans-fonts dejavu-sans-mono-fonts dejavu-serif-fonts
Do I need the source code for the Amsterdam Modeling Suite?¶
No, usually you don’t need the source code. We collaborate with all major hardware vendors to port and optimize our code on the most popular platforms. The binaries work out-of-the-box in parallel with fast interconnects through included MPI libraries or with the native parallel libraries (MPT, POE). The binaries are also shipped with linked-in mkl libraries, and are thoroughly tested against a test set before they are released. Should the latest binary for your system not be available, we are happy to help you port it to your platform. If you are an experienced system administrator you can also compile AMS yourself e.g. on an unusual supercomputing platform. In this case we do not charge you for using the source code.
Only when you want to modify the source code to use non-standard options and features do you need to purchase the source code. Changes in the compiler flags, which have been carefully optimized for performance and robustness, are not recommended and the use of different compiler flags is at your own risk.
Scientists interested in further developing the Amsterdam Modeling Suite should e-mail (info@scm.com) us to discuss a possible collaboration with SCM, including a discounted (source code) license.
What level of support can I expect?¶
Customers recommend us for the level of support and expertise of our staff. At SCM, the people developing the code are the people giving technical support.
This includes all technical aspects related to installation and bugs, and we sometimes also give some more scientifically oriented help. The latter is done only at SCM’s discretion and is not included in the official standard support.
While we sometimes like to help inexperienced users to get started, we do expect researchers to get a grasp of the theoretical methods and relevant literature. You could also reach out to the scientific community through our ADF mailing list and other channels.
We cannot guarantee to fix a particular problem or answer any question, but we will do our best to help you!
Should I use SMT/hyperthreading or only physical cores? What about E and P cores?¶
Hyperthreading does not speed up your ADF (or BAND, DFTB, ReaxFF) calculations, so it is not recommended to enforce this (by using a license for more cores and setting NSCM to double the number of physical cores). For licensing purposes, we only count physical cores. So, for instance, a hexa core machine with hyperthreading counts as six cores.
Similarly, starting from AMS2023 we do not count the E-cores for processors that use the big.LITTLE architecture where fast P cores are combined with slow but energy-efficient E cores. For such processors only the physical P cores are counted.
The Bulldozer-family of AMD architectures (Bulldozer, Piledriver, Steamroller) have only one floating point unit per two cores (module). It is thus recommended to run ADF only on half of the cores on these machines, and we try to license these machines accordingly.
For the AMD Zen generation CPUs (Ryzen/Threadripper/Epyc) ADF should run on all physical cores (without SMT). Starting with AMS2019 special Zen-optimized binaries are available that have been optimized for this CPU architecture.
How can I limit the number of processors or CPU cores used by AMS or one of the modules?¶
By default the Amsterdam Modeling Suite and its engines try to use all physical cores. So no hyperthreading and half of the cores of the some AMD architectures. To change this behavior, you need to set the NSCM variable, either in the environment, in your submit script, or in the queue definition in AMSjobs.
E.g. running from the command line on Linux:
export NSCM=4
will make ADF and other modules use 4 cores even if there are 2 or 8 physical cores.
Likewise in AMSJobs you can change your sequential queue Queue => Edit => Sequential. Enter the desired number of cores in the ‘Default Options:’ field. Since this is the default queue so if you run a job without specifying a queue or modifying the default field in AMSJobs, it will use your indicated number of cores.
What does MPI Application rank … exited before MPI_Finalize() with status … mean?¶
MPI Application rank … exited before MPI_Finalize() with status … is an error that could have occurred for several reasons. Please contact support@scm.com with:
input (.run), output (.out), logfile (.log, error (.err) for your job
your operating system (Windows 32/64 bit, Linux (distribution), MacOS (version))
which version of AMS you downloaded
How do I run and monitor remote jobs remotely?¶
It is easy to have your local GUI to set up and monitor jobs as well as visualize results, while submitting jobs to remote queues.
A video shows how to set up remote queues on Windows.
There are some conditions that must be fulfilled however. The main condition is that you must be able to log on to the remote computer using ssh (or, on Windows, plink.exe) without being asked for any passwords or confirmations. The common way for this is using public key authentication and the ssh-agent. Detailed instructions for Windows users are available in the Readme.rtf document and in its PDF version DocInstallation_windows.pdf (both in the AMS installation folder). Unix/Linux users probably already know how to do this. The other condition is: AMS must be installed on the remote machine and the commands that set up relevant environment variables must be present in the shell profile file, for example ~/.profile.
Suppose you are able to log on to the remote machine and suppose the machine is called cluster.example.com, and your login there is myname (of course you will use real values instead of these). The machine is a login node of a cluster and PBS is the batch system used on the cluster. Our experience shows that this is a very common configuration among AMS users. Now we need to configure a new queue in AMSjobs. Let’s call the queue cluster_PBS. Use the menu command Queue->New…->PBS. The template already supplies some default values but you may want to change them depending on the cluster policies.
First the easy parts: type cluster_PBS in the Queue Name field, cluster.example.com for Remote host, myname for Remote user. The Remote job directory specifies a directory on the cluster where AMSjobs will place job files.
The Run command is probably what you will want to think about more thoroughly. In the template it contains
qsub -lnodes=2:ppn=2:infiniband -lwalltime=$options “$job”
You may have to change everything between qsub and “$job” on the line depending on how PBS is configured on the cluster. This will also determine the value for the Default Options entry.
In the template, the wall clock time is configurable per job but you may decide that it is better to have the number of nodes as an option. In this case the Run command will look as:
qsub -lnodes=$options:ppn=2:infiniband -lwalltime=100:00:00 “$job”
Of course you can add there other qsub command line switches that you would normally put in the script after #QSUB. So if you choose to “hard-code” the number of nodes and leave walltime configurable then you may want to name the queue something like cluster_PBS_2nodes. If you choose to hard-code the walltime and leave the number of nodes configurable then you may want to name the queue cluster_PBS_100hr or something like that so that you can distinguish it from other similar queues that differ from this one by the hard-coded value.
After you’ve finished configuring the queue, press Save and test that you can see the status of the queue by selecting menu Queue->Status. This will query the status for each queue defined in AMSjobs by running the command specified in the System status command field (remotely if necessary). If you do not get the queue status but something like “Connection refused” or “No more authentication methods left” then check the ssh connection to the remote computer.
Finally test your queue by running a Test job.
If everything works as you like, you may consider setting your new queue as the Default Queue in AMSjobs. Then using the Run command in AMSinput or in AMSjobs will automatically assign this new queue to your job, and run the job on the remote machine.
I get a ‘libGL error’ mentioning ‘libstdc++’ in AMS2021 or older¶
This is error is caused by the GUI trying to use the packaged libstdc++, which is older and incompatible with your system libstdc++ needed for your graphics drivers.
The solution is to move the packaged libstdc++. This is done with:
mkdir $AMSBIN/libold
mv $AMSBIN/lib/libstdc++* $AMSBIN/libold/
From AMS2022 onwards this issue is solved with a dependency checker.