[RMCProfile-users] Coordination Constraints question
King, Graham Missell
gking at lanl.gov
Mon Sep 14 20:44:47 BST 2015
Helen,
Thank you for providing the keywords. I was just looking back at an email string I had with Matt and Martin in 2011 and I realized there is another question I should have asked in my initial email. They said that the coordination constraints won't work with atom swapping. As that is what I intend to use them for can I ask if they will now work along with swapping?
I also seem to be having an issue downloading the newest version of RMCProfile. When I try to retrieve my password it says it does not recognize my email as a username, but when I try to register it won't let me because it says my email is already registered. Also, I can't take a look at the 6.5.2 manual without downloading the new package because the link in the manuals tab is still for version 6.5.0.
-Graham
________________________________________
From: rmcprofile-users [rmcprofile-users-bounces at rmcprofile.org] on behalf of helen.playford at stfc.ac.uk [helen.playford at stfc.ac.uk]
Sent: Friday, September 11, 2015 1:28 AM
To: rmcprofile-users at rmcprofile.org
Subject: Re: [RMCProfile-users] Coordination Constraints question
Hi Graham,
Yes, I reinstated this constraint in the latest release, so as long as you are working with the current downloadable version of the program you can use the following (for example):
FIXED_COORDINATION_CONSTRAINTS :: 1
>CSTR1 :: 2 1 0.0 2.0 4 1.0 0.00001
Where the numbers are in the order central atom, neighbour atom, minimum and maximum distances, desired coordination number, fraction of atoms you want to have that C.N. and the weighting for the constraint.
Please see page 42 of the version 6.5.2 manual for more information and let me know if there are any problems!
Best wishes,
Helen
-----Original Message-----
From: rmcprofile-users [mailto:rmcprofile-users-bounces at rmcprofile.org] On Behalf Of King, Graham Missell
Sent: 10 September 2015 20:48
To: rmcprofile-users at rmcprofile.org
Subject: Re: [RMCProfile-users] Coordination Constraints question
Helen,
I have a follow up question on this. Have fixed coordination constraints been implemented in RMCProfile yet and if so what is the subordinate keyword to use for those? I tried to do something with them a few years ago but was told after inquiring that they hadn't been fully implemented, but after seeing this I'm wondering if I can try again.
-Graham King
________________________________________
From: rmcprofile-users [rmcprofile-users-bounces at rmcprofile.org] on behalf of helen.playford at stfc.ac.uk [helen.playford at stfc.ac.uk]
Sent: Tuesday, August 25, 2015 4:53 AM
To: rmcprofile-users at rmcprofile.org
Subject: Re: [RMCProfile-users] Coordination Constraints question
Hi Dylan,
Hopefully I can answer your questions.
1) What is this the correct syntax? I am basing it off of the keyword listed in the RMC v6 manual and the syntax within the RMCA manual. RMC recognizes that I want to enforce 3 CN constraints but I receive an error "no constraint information given" so I feel that I must be missing a keyword or have botched the formatting slightly for the lines with the actual constraint info.
You're almost right with your syntax, you just need to add the subordinate keywords to your 3 lines, like so:
AVERAGE_COORDINATION_CONSTRAINTS :: 3
> CAVSTR1 :: 2 1 0. 2.4 4.6 0.00001
> CAVSTR2 :: 3 1 0. 2.4 4.6 0.00001
> CAVSTR3 :: 4 1 0. 2.4 5.8 0.00001
2) I would like to add a coordination constraint for atom #1 (oxygen in this case) so that is has a total coordination of 2 with any combination of Ga, Zn, and In. Is this possible or can these constraints only be created between 2 specific atoms? Is there any way to indicate a set of atoms or have a wildcard?
Sadly I can't think of a way to do this with the existing coordination constraints code. You would have to group Ga, Zn and In into a single "grey" atom type, but you would then lose the ability to treat them differently (e.g. different scattering powers) during the refinement. You might want to look in to the "distance window" constraint which makes sure that all of an atom's nearest neighbours are within a specified distance range (but does not care about type or number). However this constraint will not work if the starting model has *no* atoms within the correct ranges.
3) Can I use non-integer values for the average coordination number? I have some EXAFS data that suggests the average for the samples I am examining is around the numbers listed above. It would certainly be possible for me to use FIXED_COORDINATION_CONSTRAINTS and change it to integer values and then change the percentages to get the fraction I want but I would like to start with trying enforcing an average first rather than dictating specific coordination numbers that are allowed.
Yes, I believe the non-integer values should be fine for the average coordination constraints.
4) Should I use MOVEOUT or refine to a null dataset to ensure the system fits these constraints before doing an actual refinement or is this unnecessary for this type of constraint?
The constraint will try to drive the configuration to a state which meets the criteria you give (how quickly and how completely it works is dependent on how strongly weighted the constraint is, and what other terms it is competing against in the minimisation), so in theory it doesn't matter what your starting point is. However as with any amorphous system the choice of starting point will strongly influence the final result: a random starting point will likely produce a model that is too disordered, a crystalline starting point will produce a model which is biased by the crystal structure, and so on. For this reason it is usually a good idea to build a chemically and physically plausible starting model (e.g. using MD simulations) before you start. You certainly can run RMCProfile with no data and the coordination constraint to build a starting model, and this is something I have done myself, but it requires caution. I would always produce multiple starting points in this way and analyse refined results for common features, rather than assuming a single result is correct (of course this caveat actually applies to RMC in general, not just amorphous materials!).
I hope this is useful, please get in touch if you need further help or advice.
Best wishes,
Helen
-----Original Message-----
From: rmcprofile-users [mailto:rmcprofile-users-bounces at rmcprofile.org] On Behalf Of Dylan Fast
Sent: 14 August 2015 00:09
To: rmcprofile-users at rmcprofile.org
Subject: [RMCProfile-users] Coordination Constraints question
Hello,
I have recently been working on some comparative trials for doing RMC work on a mixed metal oxide (InGaZnO4). I was directed to the old RMCA manual when looking at coordination constraints which sounds useful since I am working on a completely amorphous system.
The syntax I am using to add these constraints to the .dat file are as follows
AVERAGE_COORDINATION_CONSTRAINTS :: 3
> 2 1 0. 2.4 4.6 0.00001
> 3 1 0. 2.4 4.6 0.00001
> 4 1 0. 2.4 5.8 0.00001
General format is
"ATOM 1" "ATOM 2" "Min Dist. for CN" "Max Dist. for CN" "Avg. CN"
"Weighting factor"
I have a few questions regarding the use of these.
1) What is this the correct syntax? I am basing it off of the keyword listed in the RMC v6 manual and the syntax within the RMCA manual. RMC recognizes that I want to enforce 3 CN constraints but I receive an error "no constraint information given" so I feel that I must be missing a keyword or have botched the formatting slightly for the lines with the actual constraint info.
2) I would like to add a coordination constraint for atom #1 (oxygen in this case) so that is has a total coordination of 2 with any combination of Ga, Zn, and In. Is this possible or can these constraints only be created between 2 specific atoms? Is there any way to indicate a set of atoms or have a wildcard?
3) Can I use non-integer values for the average coordination number? I have some EXAFS data that suggests the average for the samples I am examining is around the numbers listed above. It would certainly be possible for me to use FIXED_COORDINATION_CONSTRAINTS and change it to integer values and then change the percentages to get the fraction I want but I would like to start with trying enforcing an average first rather than dictating specific coordination numbers that are allowed.
4) Should I use MOVEOUT or refine to a null dataset to ensure the system fits these constraints before doing an actual refinement or is this unnecessary for this type of constraint?
Please let me know if any of this is unclear and I will be happy to explain/elaborate.
Best Regards,
Dylan Fast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rmcprofile.org/pipermail/rmcprofile-users/attachments/20150813/dae6dad3/attachment.html>
_______________________________________________
rmcprofile-users mailing list
rmcprofile-users at rmcprofile.org
http://lists.rmcprofile.org/mailman/listinfo/rmcprofile-users
_______________________________________________
rmcprofile-users mailing list
rmcprofile-users at rmcprofile.org
http://lists.rmcprofile.org/mailman/listinfo/rmcprofile-users
_______________________________________________
rmcprofile-users mailing list
rmcprofile-users at rmcprofile.org
http://lists.rmcprofile.org/mailman/listinfo/rmcprofile-users
_______________________________________________
rmcprofile-users mailing list
rmcprofile-users at rmcprofile.org
http://lists.rmcprofile.org/mailman/listinfo/rmcprofile-users
More information about the rmcprofile-users
mailing list