Add element weights interface

[bryanwweber]

This PR adds an interface to the LookupWtElements C++ function (defined in src/thermo/Elements.cpp) to look up element weights by name, symbol, or atomic number. This is my first work in Cython, so recommendations and improvements are definitely welcome.

There is also a commit here (labeled BROKEN) that contains some commented out code because it causes a compiler error related to the compositionMap. I'm trying to add some way to return the element's struct as something that can be turned into a dictionary in Python, with either the symbol or the name as the dictionary index. Unfortunately, my attempt to copy the way that getMoleFractionsByName works didn't work here. Any help is appreciated.

Finally, I think it would be good to add a case-normalization somewhere in here, so the user can get the element regardless of the case of the name or symbol they type. I could do that in C++ but its ugly and involves defining a bunch of temporary strings; or I could do that in Python and make it prettier but only applicable to the Python interface. Any preference?

[speth]

Including deuterium and tritium in the list of elements starts to make things a bit messy in several locations. I wonder if they should be moved into a separate list for named isotopes?

[bryanwweber]

OK, so I pushed a few more commits here, and I think its pretty close to working how I want it to now. In Python, the intended interface is to use the Element class, as in

import cantera as ct
a = ct.Element('Ar')
b = ct.Element('argon')
c = ct.Element(18)

will all give an object with the information about argon. I think I will probably delete the other functions to get this information. The only thing that might be nice is to be able to get a list of all the elements available in Cantera, so I need to decide on an interface for that still. I think the C++ layer should be pretty much set now though. I took out all the map interfaces and dictionary building, because it didn't seem that useful once I thought of this class.

One thing I definitely need to do is add documentation, I mostly wanted to push here so that I could get this stuff on my other machines. I also need to clean up the commit history.

[speth]

using namespace std should never appear in a header file, since that forces any user code which may indirectly include this header to also be using the namespace.

[bryanwweber]

If I remove this line, I get compiler errors for several files that indirectly include Elements.h:

include/cantera/thermo/Elements.h:115:1: error: 'string' does not name a type
 string getElementSymbol(const std::string& ename);

This is on Ubuntu 14.04 with gcc 4.8.4. My cantera.conf is

python3_package = 'n'
f90_interface = 'n'
system_sundials = 'n'

How should I handle that? You said you couldn't reproduce the error, but this is definitely repeatable for me.

[bryanwweber]

This SO answer says to add the qualifier just in the header file. Is that correct then?

[speth]

Yes, exactly. In the header file you need to use the fully qualified name,
then in the cpp file you can have the 'using namespace' and use the
unqualified names.

On Wed, Dec 23, 2015, 3:14 AM Bryan W. Weber notifications@github.com
wrote:

In include/cantera/thermo/Elements.h
#314 (comment):

@@ -10,6 +10,8 @@

#include "cantera/base/ct_defs.h"

+using namespace std;

This SO answer http://stackoverflow.com/a/5527669/2449192 says to add
the qualifier just in the header file. Is that correct then?

—
Reply to this email directly or view it on GitHub
https://github.com/Cantera/cantera/pull/314/files#r48255824.

[speth]

I like the more object-oriented interface.

[bryanwweber]

OK I think this is pretty much finished now; at least, its working like I want it to. Please let me know any other fixes/changes! Thank you for all your comments already.

[speth]

The following behavior is probably not desirable:

>>> foo = ct.Element('Carbon')
>>> foo.name
'calcium'

[bryanwweber]

That does seem less than desirable... One way to fix this is to define two methods instead of one for the string lookup, one for the name and one for the symbol, and if users specify a string they have to specify if its the name or symbol:

ct.Element(name='Carbon')
ct.Element(symbol='C')

Then the string lowercasing can be done in Python.

Alternately, would there be any problem with checking the length of the input, and comparing inputs longer than 2 characters only to the element names? I'm not sure what the input to that function is expected to be (for instance, if a user is supposed to be allowed to pass in a string with only the first two characters filled and the rest blank, that would be a problem for this method).

Finally, the last fix I can think of is to switch the order the checking is done so the whole string is checked against the whole list of names first, then the first couple of characters are checked against the list of symbols. That would be slower though.

[speth]

I think this would be my preferred solution: speth/cantera@76f63b8 This also makes the element name checks case insensitive, and changes a couple of stylistic things. You can merge these changes into your existing commits if you like.