Add DielectricFunction properties

[JosePizarro3]

Another property added to the list. In this case, there is a renaming to Permittivity to be in line with the taxonomy. I have to check if we can define DielectricStrength, and how to extract it from Permittivity.

The design idea here is that we want to store a 3x3 tensor $\epsilon(q, \omega)$. If it does not depend on $q$, we can extract the absorption spectrum as the imaginary term like $I(\omega) = Im \epsilon(\omega)$. Like the spectrum has a rank=[], and the permittivity has rank=[3, 3], I just needed to create 3 sub-sections for each principal direction for the spectrum.

I also:

• Added a new utils function to extract the specific list of variables (function get_variables()).
• Added abstraction for spectrum, defining AbsorptionSpectrum as a more abstract category for XAS, EELS. I added axis as a MEnum
• I had to add KMesh (from KSpace definition #71), and I also defined Frequency for variables
• Added Permittivity.type for simpler categorization

[JosePizarro3]

Hi @ndaelman-hu, @ladinesa

I am not 100% who is better for reviewing this: I don't want comments on the schema, but rather on the implementation of functionalities and check that the testing is correct.

Let me know.

[coveralls]

Pull Request Test Coverage Report for Build 9269207816

Details

• 102 of 102 (100.0%) changed or added relevant lines in 5 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.1%) to 98.616%

---

Totals
Change from base Build 9254335937:	0.1%
Covered Lines:	784
Relevant Lines:	795

---

💛 - Coveralls

[ndaelman-hu]

I only checked the get_variables utility, as you asked.
Check whether it's really worth having it as a utility and if so, the edge cases I mentioned.

I think this shows 1 weakness of the naive flat schema, is that we need these scans to provide lookup. For small archives, there's no real issue, but I'm unsure about search at the DB level for 2 reasons:

1. the schema does not serialize the actual class. Will we be able to read in more specialized child classes?
2. I don't know how an ES query will perform on these lists. Actually, do you have any tag to look for?

These 2 questions are more general than this PR. Just something th at I noticed.

[ndaelman-hu]

Hi @ndaelman-hu, @ladinesa

I am not 100% who is better for reviewing this: I don't want comments on the schema, but rather on the implementation of functionalities and check that the testing is correct.

Let me know.

Did a small review. Btw, you can also ask @Bernadette-Mohr. I think she's more than capable providing feedback on the utility.

[JosePizarro3]

I only checked the get_variables utility, as you asked. Check whether it's really worth having it as a utility and if so, the edge cases I mentioned.

I think this shows 1 weakness of the naive flat schema, is that we need these scans to provide lookup. For small archives, there's no real issue, but I'm unsure about search at the DB level for 2 reasons:

1. the schema does not serialize the actual class. Will we be able to read in more specialized child classes?
2. I don't know how an ES query will perform on these lists. Actually, do you have any tag to look for?

These 2 questions are more general than this PR. Just something th at I noticed.

Not sure if I understand the point of the weakness. This data structure only stores the data, and in case of talking about querying, I doubt searching for specific variables would ever be a topic (but rather, that a property has a variable_cls defined).

Actually, do you have any tag to look for?

Again, I am never talking about ES in this schema.

[JosePizarro3]

Hi @ndaelman-hu, @ladinesa
I am not 100% who is better for reviewing this: I don't want comments on the schema, but rather on the implementation of functionalities and check that the testing is correct.
Let me know.

Did a small review. Btw, you can also ask @Bernadette-Mohr. I think she's more than capable providing feedback on the utility.

Thanks! I will incorporate your feedback and merge. I think it makes sense if I actually merge after #71

[ndaelman-hu]

I only checked the get_variables utility, as you asked. Check whether it's really worth having it as a utility and if so, the edge cases I mentioned.
I think this shows 1 weakness of the naive flat schema, is that we need these scans to provide lookup. For small archives, there's no real issue, but I'm unsure about search at the DB level for 2 reasons:

1. the schema does not serialize the actual class. Will we be able to read in more specialized child classes?
2. I don't know how an ES query will perform on these lists. Actually, do you have any tag to look for?

These 2 questions are more general than this PR. Just something th at I noticed.

Not sure if I understand the point of the weakness. This data structure only stores the data, and in case of talking about querying, I doubt searching for specific variables would ever be a topic (but rather, that a property has a variable_cls defined).

Actually, do you have any tag to look for?

Again, I am never talking about ES in this schema.

You mentioned before essentially copying a filtered version of this schema over into results, that's why I'm asking.
If so, we should consider the points I raised, though we can discuss it outside of this PR. If searching for variable_cls is supported, my point 2 remains.

[JosePizarro3]

I only checked the get_variables utility, as you asked. Check whether it's really worth having it as a utility and if so, the edge cases I mentioned.
I think this shows 1 weakness of the naive flat schema, is that we need these scans to provide lookup. For small archives, there's no real issue, but I'm unsure about search at the DB level for 2 reasons:

1. the schema does not serialize the actual class. Will we be able to read in more specialized child classes?
2. I don't know how an ES query will perform on these lists. Actually, do you have any tag to look for?

These 2 questions are more general than this PR. Just something th at I noticed.

Not sure if I understand the point of the weakness. This data structure only stores the data, and in case of talking about querying, I doubt searching for specific variables would ever be a topic (but rather, that a property has a variable_cls defined).

Actually, do you have any tag to look for?

Again, I am never talking about ES in this schema.

You mentioned before essentially copying a filtered version of this schema over into results, that's why I'm asking. If so, we should consider the points I raised, though we can discuss it outside of this PR. If searching for variable_cls is supported, my point 2 remains.

I am still not sure. In results there will be a reference to the specific property (e.g., permittivity). The variables will never be searched, but probably it will be filtered to the result which variables we want to make searchable. This is as optimal as whatever is already in place for the results section when it is referencing properties in run.

Maybe I used wrong the word "copy"?

[JosePizarro3]

I think I will be merging this tomorrow morning! No problem, we can revisit this as well in the future.