Features/improvements for upcoming version v0.4

[dgehringer]

👋 Hello everyone

I currently plan to give sqsgen a major rewrite. While most the changes should go unnoticed by users, the rewrite will involve architectural 🏗️ changes to the core library.

Therefore, I thought it would be a good to ask users for their, feedback, feature wish list and enhancement suggestions.

📬 If you know someone who uses sqsgenerator, please forward this page
💡 Please post your ideas for enhancements below (framework integration, custom objectives?, output formats, HDF?, etc., run it as a service) whatever comes to your mind

Here's a list of planned tasks:

• ⚡️(minor) performance improvements - optimised versions for special cells or number of species
• 🚸 remove ambiguity when defining optimisations involving multiple sub lattices.
• 📦 bring the package to pip also
• 👨‍💻 improved Python API
• 🔙 better support for callbacks
• 🔍 better analysis of existing structure
• 🧱 better integration with @pyiron (maybe @dhoulek, @aminsakic or @jan-janssen) could support here
• 🔥 drop support for Python <= 3.8 (maybe even 3.9 as it reaches EOL end of next year)
• 🌐 (maybe ❓ ) generate JS bindings and serve it as a WASM module (depends if emscripten supports C++20 by then)
• 🏗️ refactor 🐍 Python bindings (not important for users)
  • 🏷️ full mypy type-hint
  • 🗑️ remove "glue" code
• ⬆️ Upgrade to C++20 (not important for users)
• ✅ improved unit test coverage
• ➖ remove dependencies (not important for users)
  • 📦️ Python packages
  • 📦️ boost as it brings a lot of complexity to the CI (not important for users)

🔈 Feel free to post your suggestions and ideas so that we can discuss them

👥 If you want to (or possibly you know someone who wants to) contribute also with your code, please do not hesitate to contact me

[angus-gentles]

Hello all,
I use this program extensively, but have had some difficulties with getting it set up on a cray architecture, conda being poorly optimised for this.

Firstly, it might be advantageous to be able to dump all output parameters and optimisation functions into a separate output file? I have some intuition telling me that many of the outputs might be very limited, and that the parameters could be clustered around several values. It could be a very long file, but i do believe it could be useful.

Secondly[defunct], might it be possible, as the above comment notes, to include the 'which' functionality into the input files that don't include .cif inputs. It is not specified that this should be for only the .cif files, but I would like to completely discount one sublattice from my optimisation.

Edit: I have realised that it was a mistake with my formatting of the input file.

[dgehringer]

Hi @angus-gentles!

Many thanks for reporting you experience!

1.) Building on HPC platforms: Yes conda (environment) is definitely not optimal in all HPC settings. However, it is an easy way to to deploy a package with complex dependencies. The current state of version v.04 is, that for HPC settings a custom (native) CLI app will be available. I have also migrated the build system to vcpkg. So to build the project only Git and CMake will be required.

2.) dumping SRO parameters: With the current version it should be possible to dump the output into the resulting YAML file. --dump-include parameters should do the job. For the output interpretation a note is given in the documentation.

In the new version the output file won't be a YAML but a custom binary format that contains (user config, optimisation related config, statistics, all structures and all parameters) one will be able to export structure using the CLI app, and further analyse the output SRO using Python. The advantage ist that YAML becomes unhandy when it grows to large.

The native CLI app will take an input file (sqs.json) and produce an output file (sqs.mpack) which can be later analysed further.

3.) which-parameter. We will drop the which parameter in the new version, there will be however, a more powerful replacement for it. More specifically the pogramm can operate in "interact" mode, where a sub lattice is embedded and all lites sites are used in the optimisation. In contrast in the new "split" mode, the program will "split-off" the specified sub lattice and optimise it independently. Therefore one will be able to optimise multiple sub lattices at once, or as in your case if the sub lattice specification is not exhaustive with respect to the initial lattice sites, perform the optimisation just on a subset of the lattice sites and subsequently discount the remaining sub lattice from the objective function!

[angus-gentles]

Fantastic, thank you very much. You preceded the point i was going to ask about the which parameter that i was just trying to phrase properly. For the SRO parameters, I meant the intervening stages. At the moment only the well optimised arrangements are shown, whereas I would like to find the poorly optimised cells too and see what parameters they produce.

Also i like the yaml output files. They are very easy to scrape oneself without a separate interface.

[Leo3701]

Hi!
I currently use sqsgen to produce a series of SQS structures of high entropy alloys with different composition combinations. I wonder if it is possible to add a function like a loop to enumerate the composition combinations and print the corresponding structures.

[dgehringer]

Hi @Leo3701 !

Hmm ... I'm not at 100% sure what you mean exactly with enumerate the composition combinations. Currently the SQS optimisation runs at one single and fixed composition. Do you mean you want to sample the compositional space?

[dhoulek]

This sounds to me more like a postprocessing of the sqsgen evaluation and/or running sqsgen in loops. As discussed with @dgehringer, the idea is to keep sqsgen as light as possible (i.e. as single-task-orientated as possible), and outsource such specialized tasks into Jupyter notebooks.

That said, it would be interesting, if @Leo3701 can expand on his ideas so that we can prepare and provide notebooks with a large variety of tasks related to sqsgen useful for the community.

[SR333Chris]

Dear maintainer. Thanks for your great work in providing another way to build structures with SQS.

In my preliminary test (TiAlN and TiAlN-based systems with B1-NaCl structure), both the calculated energy and the variation trend of elastic constants for the two kinds of structures (sqsgen and ATATsqs) are in accordance. However, the structures built by sqsgen may be a little bit 'brittle' than those built by ATATsqs and the results in the literature holistically.

Although I think it will not influence the correctness of the calculation results as long as all the structures were built in the same way. I'm concerned it may be attributed to my YAML input, especially the setting for shell_weights, or it is just a systemic influence. And is there any advice on how to adjust the shell_weights, or is it well enough to choose the default values?

Thanks a lot for your excellent project. Here is my YAML input and test results:

structure:
supercell: [2, 2, 2]
  file: /public/home/hpc233312127/software/sqsgenerator/TiN.vasp
  format: vasp5
iterations: 5e6
shell_weights:
  2: 1
  4: 0.4
  5: 0.2
composition:
  Ti:
    Ti: 16
  Al:
    Ti: 16
  N:
    N: 32
prefactors: 0.5
prefactor_mode: mul

[dgehringer]

Hi @SR333Chris!

Many thanks for your interest in the program.

I have to admit that I myself was not a ATAT user, while I have heard a lot of it and people in my former working group used it also.

Given that I am not 100% sure on what ATAT actually does. However, let me give you some context on the snippet you have where the parameter "prefactors" and "prefactor_mode" are set.

Basically there are two ways of thinking when doing such an optimisation:

1. You think of the whole structure as a single whole structure and then you optimize all SRO parameters in your case (leaving aside same atoms pair bonds) Al-Ti, Al - N and Ti - N. If this is your intent I would suggest to remove the "prefactors" and "prefactor_mode"

2. Or you say will only the atoms at the metal sub lattice mix and I do not care and I do not care about species sitting on the Nitrogen sub lattice. In this you'd optimize only Al-Ti bonds. You do not care about Al - N bonds, Ti - N bonds. Then I suggest to again to remove "prefactors" and "prefactor_mode" and set which: Ti and remove the Nitrogen section from the composition.

It depends a little bit agains what you compare it to.

"prefactor_mode" came from the restriction that one could only optimize one sub lattice at a time. If you wanted to optimize more sub lattices (assuming that do not interact with each other) in a single run. E.g. if you wanted to create e.g. TiN -> (Ti,Al)(Cr,N) this parameter were introduced. This was a possible way to do it however, it had some flaws, namely this strange setting of the "shell_weights"

In the upcoming version I have introduced sub lattice "modes" namely that address exactly this issue. Those are called interact which corresponds to 1.) and split which corresponds to 2.)

pre-release pip wheels are already available, I'm still fighting with the conda CI.

[SR333Chris]

Thank you very much for your great suggestions! I misunderstood the function of "prefactor_mode" and "shell_weights" before, and just copied the setting in the (Ti, Al)(B, N) example from "advanced topics".

Meanwhile, this program and the articles from David et al. provide another viable way for us to deal with the magnetic problems of Cr in transition metal nitride systems. Congrats on your fantastic work!

[dhoulek]

Dear Chris, May you please expand a bit on what do you mean by “being brittle”? Thanks, David

…

On Sat 26. Jul 2025 at 12:51, dgehringer ***@***.***> wrote: Hi @SR333Chris <https://github.com/SR333Chris>! Many thanks for your interest in the program. I have to admit that I myself was not a ATAT user, while I have heard a lot of it and people in my former working group used it also. Given that I am not 100% sure on what ATAT actually does. However, let me give you some context on the snippet you have where the parameter "prefactors" and "prefactor_mode" are set. Basically there are two ways of thinking when doing such an optimisation: 1. You think of the whole structure as a single whole structure and then you optimize all SRO parameters in your case (leaving aside same atoms pair bonds) Al-Ti, Al - N and Ti - N. If this is your intent I would suggest to remove the "prefactors" and "prefactor_mode" 2. Or you say will only the atoms at the metal sub lattice mix and I do not care and I do not care about species sitting on the Nitrogen sub lattice. In this you'd optimize only Al-Ti bonds. You do not care about Al - N bonds, Ti - N bonds. Then I suggest to again to remove "prefactors" and "prefactor_mode" and set which: Ti and remove the Nitrogen section from the composition. It depends a little bit agains what you compare it to. "prefactor_mode" came from the restriction that one could only optimize one sub lattice at a time. If you wanted to optimize more sub lattices (assuming that do not interact with each other) in a single run. E.g. if you wanted to create e.g. TiN -> (Ti,Al)(Cr,N) this parameter were introduced. This was a possible way to do it however, it had some flaws, namely this strange setting of the "shell_weights" In the upcoming version I have introduced sub lattice "modes" namely that address exactly this issue. Those are called *interact* which corresponds to 1.) and *split* which corresponds to 2.) pre-release pip wheels are already available, I'm still fighting with the conda CI. — Reply to this email directly, view it on GitHub <#48 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN2VQSUU67UF7XZPWSLYDQ33KNMSZAVCNFSM6AAAAABQ4WZFVCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGOBZGU4DIMY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[SR333Chris]

Dear David,

The "brittle" comes from the calculated semi-empirical indicator B/G and Cauchy Pressure values by the stress-strain method. I guess it may be attributed to more Al-Al interaction in the structures formed based on my previous setting. However, after I adjusted the input file as suggested by @dgehringer, the current calculated results are much closer to structures built by ATAT.

Thanks,
Chris

[dhoulek]

Dear Chris, While I am happy you could resolve your concerns, I do not understand it scientifically: how could you have elastic constants in accordance, but not the B/G (which are calculated from Cij)? Best wishes, David

…

On Fri, 1 Aug 2025 at 10:07, SR333Chris ***@***.***> wrote: Dear David, The "brittle" comes from the calculated semi-empirical indicator B/G and Cauchy Pressure values by the stress-strain method. I guess it may be attributed to more Al-Al interaction in the structures formed based on my previous setting. However, after I adjusted the input file as suggested by @dgehringer <https://github.com/dgehringer>, the current calculated results are much closer to structures built by ATAT. Thanks, Chris — Reply to this email directly, view it on GitHub <#48 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN2VQSXKBEDUVGWH43AWV5L3LMN2XAVCNFSM6AAAAABQ4WZFVCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGOJVGYYTAMQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[SR333Chris]

Many thanks. I got what you mean right now. I wanted to suggest that the variation trend of B/G (which is calculated from Cij) with Ti substituted by W is the same by two different methods; however, the elastic constants presented a little bit different at the same composition.

[dhoulek]

Can you be a bit more specific about what "a bit different" means? There will always be some dependence on the actual SQS, and even within the SQS, there will be differences between $x$, $y$, and $z$ directions. There are, of course, unphysical effects caused only by the small size of the used cell, and become pronounced in particular for tensorial properties such as elastic constants. We have discussed this issue in this paper: [10.1103/PhysRevB.90.184106](https://journals.aps.org/prb/abstract/10.1103/PhysRevB.90.184106) David

[SR333Chris]

The 'bit difference' is mainly about the difference in C44 (215.892 (based on my previous input setting) and 203.505 (ATAT structure) for Ti0.5Al0.5N by two kinds of structures, respectively).

Thanks a lot for introducing your paper to help me further study it! I can get the influence of cell size by browsing through this paper; however, I need a little time to read it intensively to understand it as fully as possible.

Best wishes,
Chris

[dhoulek]

Personally, I would not be concerned so much about the 10 GPa difference, which is about 5%. As a test, try to generate several SQSs and get C44 for those. What is the spread, then? My guess would be that it can easily be in the same range, although all structures have the same SRO. Another point for consideration: How much does C44 differ from C55 and C66? Best regards, David

…

On Fri, 1 Aug 2025 at 12:58, SR333Chris ***@***.***> wrote: The 'bit difference' is mainly about the difference in C44 (215.892 and 203.505 for Ti0.5Al0.5N by two kinds of structures, respectively, based on my previous input setting). Thanks a lot for introducing your paper to help me further study it! I can get the influence of cell size by browsing through this paper; however, I need a little time to read it intensively to understand it as fully as possible. Best wishes, Chris — Reply to this email directly, view it on GitHub <#48 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN2VQSRY4FYN244NBK6QXYD3LNB5LAVCNFSM6AAAAABQ4WZFVCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGOJVG43TENA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[SR333Chris]

Thank you for your suggestions. Actually, I was more concerned that there was something wrong with my input file at the beginning, rather than the slight difference, and @dgehringer has helped me to resolve it. The little difference is acceptable, and I also agree that it can easily be in the same range as long as all structures have the same SRO.

Due to I have restricted the symmetry of all the structures to space group 225 (B1 structure) during calculation, the C55 and C66 haven't been calculated.

Thanks,
Chris

[dhoulek]

Hang on - how can you restrict the symmetry when generating the SQS? I think this is not possible with the current version of sqsgenerator. So, the correct way of calculating the elastic constants is to calculate the full matrix of elastic constants (6x6 Cij matrix) and then to project it on the desired symmetry (10.1007/s10659-006-9082-0). This, for the cubic system, means averaging: C11(B1) = (C11 + C22 + C33)/3 C44(B1) = (C44 + C55 + C66)/3 David

…

On Fri, 1 Aug 2025 at 13:56, SR333Chris ***@***.***> wrote: Thank you for your suggestions. Actually, I was more concerned that there was something wrong with my input file at the beginning, rather than the slight difference, and @dgehringer <https://github.com/dgehringer> has helped me to resolve it. The little difference is acceptable, and I also agree that it can easily be in the same range as long as all structures have the same SRO. Due to I have restricted the symmetry of all the structures to space group 225 (B1 structure) during calculation, the C55 and C66 haven't been calculated. Thanks, Chris — Reply to this email directly, view it on GitHub <#48 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN2VQSQCIT3MXQT5566E62D3LNIVFAVCNFSM6AAAAABQ4WZFVCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGOJVHAYTMNA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[SR333Chris]

Here is a little bit misunderstanding. I haven't restrict the symmetry when building structures. I restrict it at the pre-processing of elasctic constants calculation (after structures build by SQS have fully relaxed) to reduce the calculation costs during my tests. The value of C44 C55 C66 usually similar (also C11 C22 C33) for fcc-TiAlN and it can help me to get some of the trend (like the effect of elements doping on the elastic constants) by a cheap calculation cost for tests; however, it is more correct to calculate the full matrix of elastic constants.