Comments (5)
I'm for it. As far as directory structure is concerned, this is something that has long bothered me as well. If we want to be anal, we could leave the old directories under include/aspect and have an interface.h in each that simply #includes the new one, but I think even that may not be necessary. I'd think people understand that they might need to update their plugins between ASPECT versions.
I currently have 4 big branches open. Can we make these changes once all big branches have been merged?
I don't know whether you intended to also rename the sections in the .prm files to be more consistent. That's a bigger issue because it breaks everyone's .prm files. I think this may be too much to be worth the pain.
from aspect.
Yes renaming the sections in the parameter files seems to be a bit too much. However I ran into a similar inconsistency that might be worth thinking about for a moment. We map boundaries to different velocity boundary condition plugins, but assume that one plugin can describe all boundary conditions for temperature and composition. I currently need temperature boundary conditions that are different depending on the boundary indicator. I will write my own boundary temperature plugin, but what it will do is essentially using the existing initial_temperature plugin code for every boundary except from the bottom boundary, so a similar map as we use for the velocity could save me from copying that code to a new plugin.
Would this be worth considering? Unfortunately, it would mess up the input files as well.
And of course we can wait with the above mentioned renaming until no large branches are awaiting their merge to keep conflicts as small as possible.
from aspect.
change directory structure
agreed
leave the old directories under include/aspect
I am not too thrilled about it.
break .prms
I think this is okay to do. The current naming is quite confusing. If we change the directory structure the sections and directories should match up and not be different.
We map boundaries to different velocity boundary condition plugins, but assume that one plugin can describe all boundary conditions for temperature and composition.
This is also a good idea. Things handled in a uniform way is a big plus.
from aspect.
I vote for also redoing the parameter sections while we are at it and make it more flexible. I was thinking something like this:
subsection boundary conditions
subsection Velocity
set conditions = left: tangential, right: zero, top: function, bottom: SomePluginName
subsection function
set function = bla
end
end
subsection Temperature
set conditions = left: periodic, right: periodic, top: function, bottom: initial
end
subsection Initial conditions
like above
end
The idea is that there is one list for the indicators and you can pick between all kind of plugins and different types of boundaries.
This has many advantages:
- it is more flexible (right now you can only pick a single model for temperature)
- easier to validate that each boundary has exactly one condition (in the code and for the user)
- it is the same for all types of boundaries
from aspect.
from aspect.
Related Issues (20)
- Not converging cookbooks
- Symlink for aspect-release HOT 4
- Improve the way we describe the way to create plugin libraries.
- aspect.release vs aspect-release HOT 1
- Make Peierls approximation more efficient
- random failure in tests/world_builder_select_grains HOT 2
- Modify Stress limiter in VP? HOT 1
- Update to particle composition HOT 5
- An error and its solution "bash: /home/ubuntu/aspect/aspect: No such file or directory"
- Deformed cell for 3D mesh deformation in release mode HOT 4
- Test viscoplastic material model
- Warning: handling deprecated packages HOT 4
- deal.II-v9.5.2 missing bundled directory HOT 8
- Move FastScape restarting functionality into the ASPECT checkpointing framework
- Fixed compositional field (and temperature) boundary conditions on deforming boundaries HOT 1
- Continental extension cookbook fails with gmg solver HOT 4
- contrib/utilities/update_scripts/source_files out of date
- MPI error installation main HOT 3
- Build ASPECT in 'release mode only' causes external plugins to not compile HOT 2
- Document default boundary condition for Stokes solve
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 aspect.