Comments (13)
Can 'averaging_scheme' also become an input to the Composite? Do we need a new class for this?
Composite could just have functions for the moduli, velocities, and depth (giving P and T), and pressures (giving depths and T). These only work if you have fractions and averaging_scheme defined. I like the individual functions, this way, if you change the fractions or averaging_scheme, it would also get recomputed.
Also the misfit functions in main.py could go into tools.py or a new misfitfunctions.py. These two things would empty out main.py.
from burnman.
I generally agree, Sanne. It would certainly simplify things to be able to ask a Composite
for its averaged properties.
from burnman.
I also agree. I made a start on this in #138 yesterday, but the elasticity/thermodynamics averaging isn't finished yet.
One question - before now, there has always been the option to input a bunch of P,T points, but with composite (and mineral, and solid solution) only one P,T point is input during set_state. Is this a problem?
I think depths should not be an input to composite - perhaps some higher level function could be added to burnman.tools to calculate pressure-depth curves for a sphere/infinite half plane of constant composition/layered composition? Eventually, of course, this is something for which equilibrium calculations will be necessary...
from burnman.
I like the idea of being able to compute things individually or as a group. If we do this for Composite, maybe it would be good to also do this for Mineral and SolidSolution? The only issue is that it will need a rewrite, removing attributes and replacing with functions, such that we have things like
pyrope.set_state(P,T) # essentially does nothing apart from updating P, T
pyrope.gibbs() # actually does the calculation
This is a pretty hefty change, but it would vastly increase efficiency...
from burnman.
The reason for the current design is how we designed Material
: For a given P,T you can unroll() a material into an array of phases and fractions, but the phases/minerals can change depending on P and T. This basic design allows for things like switching between two mineral phases based on P for example.
I don't see how we can make this work for a list of P,T values without rewriting pretty much everything.
from burnman.
Was that an answer to my first comment? If so, then I understand. I don't think it needs to be changed - I always calculate things for individual P,T points anyway.
For my second comment, any thoughts? Or alternative ways to make things faster? It seems like this is our last chance to make any big changes...
from burnman.
I was commenting on
One question - before now, there has always been the option to input a bunch of P,T points, but with composite (and mineral, and solid solution) only one P,T point is input during set_state. Is this a problem?
And the answer is that I don't see an easy way to change this.
For my second comment, any thoughts?
What are you referring to?
from burnman.
Ok, we're on the same page w.r.t the first comment :)
My second comment was this:
"I like the idea of being able to compute things individually or as a group. If we do this for Composite, maybe it would be good to also do the same for Mineral and SolidSolution? The only issue is that it will force a rewrite, removing attributes and replacing with functions, such that we have things like
pyrope.set_state(P,T) # essentially does nothing apart from updating P, T
pyrope.gibbs() # actually does the calculation"
Essentially, my question is how to optimise efficiency (calculating only the required variables) whilst ensuring that the user doesn't end up taking values for variables which haven't been updated since before the last set_state. We discussed this last December, but I guess it got shelved.
Sanne's point about having functions to compute elastic moduli etc. might be a nice way to solve the efficiency problem. Another alternative might be to delete attributes each time set_state is called and reinitialise them with some optional functions. The user input for each method would look something like this:
Current method
rock.set_state(P, T)
rock.gibbs
rock.G
Possibility 1
rock.set_state(P, T)
rock.gibbs()
rock.G()
Possibility 2
rock.set_state(P, T, "thermodynamic")
print rock.gibbs
rock.set_state(P, T, "all")
print rock.G
There are issues with all three. The current method is elegant, but does force the user to compute everything for each set_state (slow even for simple calculations, which is why I implemented calcgibbs). The second method is also elegant, and will be much faster for most purposes, but does force a rewrite, and might be slower if the user needs to compute a lot of related variables. The third method will be backwards compatible, and will potentially be very efficient, but will need careful deletion of attributes for each set_state to make sure the user doesn't use old values by accident.
I'm happy to stick with the old method, but thought I'd bring this up now. Any thoughts?
from burnman.
I played with computing properties on demand inside EOS here 1. This way things are not computed when you don't need them and we avoida ton of recomputation of things too. I guess we never continued with this.
There is also python properties (see 2) that allows you to write a function get_G()
that is called behind the scenes whenever you access rock.G
.
from burnman.
Oooh, python properties are cool! I didn't realise those existed, thanks Timo! What do you think, might that be a good way to go? From the user point of view, there would be no change, which is definitely a plus!
from burnman.
An additional point - I don't think we should have setters and deleters, so in this case, attributes would be as simple as:
@property
def x(self):
self._x = 1.0
return self._x
Short, simple, easy to maintain - I like it!
from burnman.
What do you think, might that be a good way to go?
I think we should keep the set_state
interface. Down the road we can use properties, lazy evaluation, and caching in Material
and EOS
. The good news is that we don't need to worry about optimization now and don't have to change the interface later.
For now we should get the changes to the interfaces of Composite
that you need right.
from burnman.
Before we do optimizations a benchmark needs to be set up to measure the improvements and to be able to check accuracy of the changes.
from burnman.
Related Issues (20)
- polytopetools HOT 9
- Sanitise Solution object instantiation HOT 1
- Burnman readable files HOT 6
- solution model with vacancies, Fe2+ and Fe3+ and site partitioning HOT 1
- Manuscript: Improve clarity on mineral phase proportion calculations HOT 1
- Manuscript: Reference jupyter notebooks in tutorial directly in paper HOT 1
- Clarification on optional dependencies HOT 3
- Docstrings: Argument names are smooshed together with argument types HOT 1
- Manuscript and DocString: Clarify equilibrate() function HOT 2
- Manuscript: Text suggestions HOT 2
- Tests failing due to updates in required module(s) HOT 1
- tutorial_01: missing example of ideal melt model HOT 1
- tutorial_03: Suggestion for extra explanation in planet Zog creation HOT 1
- Request: net tutorial to create tabulated EOS for ASPECT
- Improve fitting functions
- Use numpy arrays in place of numeric lists, remove zips
- Sanitize autodoc section of the manual
- Preserve phase composition when transforming solution basis
- Implement derivative properties in CORK EoS
- Add mineral library docstrings
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from burnman.