Comments (12)
It's shipping today; working on docs and some final decisions for how limbs should work for a package like mdsynthesis to avoid namespace clashes with upstream limbs. Ran out of time yesterday before finishing this work up.
from mdsynthesis.
Docs are done as far as I can tell; please give a quick read and see if anything feels missing or off. I'm too involved to have fresh eyes on them: http://mdsynthesis.readthedocs.org/en/develop/
from mdsynthesis.
Not strictly related, but the links in the readme on the repo are a little borked. datreant_
has an underscore and there's a :ref:
somewhere
from mdsynthesis.
@richardjgowers thanks for catching that. The README isn't the point of entry for users, but I did lift some of the rewritten intro text from the docs and put it there. Forgot to replace the sphinx-parsed bits with components that would work for raw RST.
from mdsynthesis.
docs:
- I would make the first mentioning of
Sim
an actual link to the class definition - dependency: MDAnalysis >= 0.15? That's not even out yet...
- Also make
Sim
a link in the Leveraging Sims section. Can you use intersphinx links to makeMDAnalysis.Universe
a link? (perhaps use~MDAnalysis.core.AtomGroup.Universe
?) - Treant and Sim are not always marked up.
- Too much talking about
Treant
objects --- focus on the MDSynthesis user who comes to the package the first time and does not want to (or need to) dive intodatreant
. I think the docs will need some rewriting to get rid of the developer point of view but don't do this now... for the initial release it will be fine and it's not too bad. In fact, if you just say all the things about "Sims are Treants" after having explained what you do with Sims then it would be fine. (And don't explain Sims by contrasting with Treants... not helpful for people who don't know Treants.) s.udef
vss.universe
is very confusing: If I didn't know any better I'd dos.universe.trajectory = "path/to/xtc"
... and it would even work with disastrous consequences. Perhaps makingudef.trajectory
a property is hiding to much (e.g. assigning reloads the universe?... that makes sense but seems to be a big side-effect; an explicit method call likeload_trajectory()
might be clearer)- Come to think, I guess I just dislike
s.udef
because neither the name nor the docs tell me what it is good for. s.atomselections
is really weird, syntactically and semantically: I assign a strong or a list and then I get back an AtomGroup?? I think you're abusing properties here but that might just be me. (At least you can assign an AtomGroup, so there's some balance.) I am not a fan ofs.define(key)
--- it seems decoupled fromatomselections
. But I don't have a good solution: makings.atomselections[key]
a proper object allows one to dos.atomselections[key].definition = "selection string"
(which is nice) but thens.atomselections[key].atoms
, which seems clunky: justs.atomselections[key]
would be nicer. Or makes.atoms[key]
available for eachs.atomselections[key].atoms
...- mdsynthesis.limbs.AtomSelections: The name define() has the wrong semantics: You are not issuing a command to define but you are getting a definition back. It should be
get_definition
or perhaps just a dict-like lookups.definitions[key]
(and you're even raising aKeyError
... hint, hint!)... and see above. When I encounter semantic shear in a UI (i.e. the function is different or the opposite from what the words mean in normal English) I cringe.
from mdsynthesis.
@dotsdl , it's very useful to have the UI laid out in the docs, so your docs are a success. But seeing it in this way, in context, in summary, made me realize that there are some UI choices that still feel rough or kludgey. Apologies if any or all of this had already been debated and settled previously.
from mdsynthesis.
docs:
- bottom: © Copyright 2014 ... shouldn't this be 2016?
- have a link to the GitHub repo on the first page in the text: you have datreant and MDAnalysis... but not MDS itself.
from mdsynthesis.
@orbeckst this is all extremely helpful. Thanks!
- Fixed.
- Oops...I clearly counted up one too far. I should know this. Set to 0.14
- Yeah, we use intersphinx already; made a proper link to the module where
Universe
lives. - Should they be? I tend to find it distracting if they're always plaintexted or always links. If there's consensus to do this (e.g. instead of Treant, we always say
Treant
), then I'll do it. - This is a hard problem, and I don't have a good solution for it. Much of the non MD-specific functionality, which is to say 90% of what a Sim can do, is defined in
datreant
, and doing any kind ofhelp(Sim.<methodname>)
will do lots of talking about Treants, Trees, Views, etc. I think a downside to howdatreant
andMDSynthesis
are designed is that you can't completely hide the inner library within the outer one without a lot of work that defeats the point (lots of duplication). All ears for how to sustainably go about this, though. - I agree its confusing, but a way of partitioning these things in the brain are that
udef
is the Sim's universe definition: the description of what it needs to generate its universe. The Sim'suniverse
is the result of that definition, and it should always reflect that definition. Perhaps there are better ways of doing this, but part of the reason for this is that we want to limit how much Sim imlements into its own namespace to avoid clashes with upstreamdatreant
. A Sim gives only three components in its namespace beyond what a Treant has:universe
,udef
, andatomselections
. All three of these are unlikely to every clash with upstream limbs. - See above; if I make this way of viewing
udef
explicit in the docs, would that be a solution for this? Or should we completely rethink this, perhaps by monkey-patching theUniverse
such thatSim.universe.topology = 'path/to/top.psf'
just works instead (or as well)? - I agree that this is asymmetric, and I don't like that generally. Alternatively one can always do
s.atomselections.add('lid', 'resid 122:159')
to achieve the same effect ass.atomselections['lid'] = 'resid 122:159'
. Perhaps we could add anatoms
limb as you suggest that gets backAtomGroups
from stored atom selections, leavingatomselections
to work only with the definitions? It'd be a bit different from previous limbs in that it interacts with the data stored by another, but it would work. - I agree; I've always hated the semantics of this name, but couldn't think of something that doesn't feel clunky (although they're traditional, I think
get_*
are a bit ugly). Depending on (8) above, this may be moot. Perhaps we should go that route, separating definition limb (atomselections
) from object limb (atoms
), in the same way as we do for the Universe (udef
anduniverse
)? That would bring some consistency on one dimension.
from mdsynthesis.
@dotsdl with 6 & 7, can we not just make udef
hidden to the user and just make everything work through assigning a mda.Universe?
from mdsynthesis.
@richardjgowers I actually really like that idea, and I think we can go ahead with it and see how far we get. If it turns out we need a place for tweaking how the Universe behaves that can't be done from or with the Universe itself, then we can expose udef
(remove the underscore, really).
This can go a long way toward including keyword argument persistence (see #25), since the solution arrived at for how the Universe stores these (MDAnalysis/mdanalysis#292) can be made to only have strings, bools, floats, and ints (some kwargs can be objects, so must be a mapping for those (I think we already have this for Readers)) so it is immediately extractable and storable by the Sim inside its JSON state file.
Sound good?
from mdsynthesis.
Alright, pushing to PyPI. Thanks all!
from mdsynthesis.
Hooray!
(And you even managed to close all issues in the tracker...)
from mdsynthesis.
Related Issues (20)
- Failing in adding a Universe creates bad state HOT 2
- failed to store DataFrame with column multi-index HOT 4
- One Sim, one Universe: remove multiple Universes functionality HOT 15
- Setting Sim.universe to universe with chain reader doesn't work HOT 1
- Support auxilliaries in Universe definitions HOT 3
- create sim from existing Treant HOT 4
- handle folders with several simulations HOT 2
- The current release doesn't work with MDAnalysis 0.16.0dev HOT 3
- make a 1.0 release? HOT 11
- Remove Sim treanttype HOT 3
- Move to MDAnalysis org HOT 9
- Removing all tags/categories HOT 2
- python 3 release? HOT 3
- add conversion script from 0.8 to 1.0 HOT 3
- Error when using sim.tags/sim.categories HOT 3
- So much faster! HOT 1
- Is it possible to store in data or somewhere else files or paths to them? HOT 8
- Two different documentations online? HOT 1
- Order of Treants in a Bundle HOT 3
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 mdsynthesis.