[Yade-dev] Fwd: [Yade-users] YADE documentation
Début du message réexpédié : De : Vincent Richefeu riche...@geo.hmg.inpg.fr Date : 24 juin 2009 11:23:06 HAEC À : yade-us...@lists.launchpad.net Objet : Rép : [Yade-users] YADE documentation Hi, If no objection, I propose to create a second wiki (on wikidot.com) exclusively dedicated to yade documentation. I personally use wikidot and I find it much more user-friend than wikia. I could design and propose (in a first stage) a structure for the site. Then, any contributor will be able to add pages. In worst cases, the second wiki may be deleted. Please give me your opinion about this solution, VR Le 24 juin 09 à 10:24, Anton Gladky a écrit : I think if we have as more documents as possible will be positive for new users. We can start from creating pages on wiki and then we'll see how it is better to structure in one document. __ [ENG] Best Regards [GER] Mit freundlichen Grüßen [RUS] С наилучшими пожеланиями [UKR] З найкращими побажаннями Anton Gladkyy 2009/6/23 Mohammad Nurul Islam nisla...@yahoo.com Hi, Preparation of YADE documentation will be a good step for new users.I have some own documentation that I have prepared with respect to PFC and OVAL and some other open source DEM code, manual. And I guess other YADE users also have such types of documentation.If we share each others documentations, it will enrich YADE resource. Ofcourse there are some documentation on YADE, but for new users it is questionable, how much it will be helpful !!! Regards, Mohammad Nurul Islam --- On Tue, 6/23/09, Anton Gladky gladky.an...@gmail.com wrote: From: Anton Gladky gladky.an...@gmail.com Subject: [Yade-users] YADE documentation To: Yade Development Group yade-us...@lists.launchpad.net Date: Tuesday, June 23, 2009, 8:38 AM Hi all! I have some thoughts on YADE documentation. I am working with YADE not so much time. But the main thing, what waste a lot of time, is the insufficient documentation. I'm sure it stops a lot of new potential users and (probably) developers. So my guess is, that it would be good to start from creating short but informative instructions or howtos for different tasks. It should include short description how to do it and good examples with comments. I like style which has been used for C++ tutorial http://www.cplusplus.com/doc/tutorial/ I am ready to write some of such documents, but my YADE knowledges are yet not so deep. I think it is an important to have a good and easy-understandable documentation. ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] YADE documentation
Hi, If no objection, I propose to create a second wiki (on wikidot.com) exclusively dedicated to yade documentation. I personally use wikidot and I find it much more user-friend than wikia. I could design and propose (in a first stage) a structure for the site. Then, any contributor will be able to add pages. In worst cases, the second wiki may be deleted. Please give me your opinion about this solution, VR Le 24 juin 09 à 10:24, Anton Gladky a écrit : I think if we have as more documents as possible will be positive for new users. We can start from creating pages on wiki and then we'll see how it is better to structure in one document. __ [ENG] Best Regards [GER] Mit freundlichen Grüßen [RUS] С наилучшими пожеланиями [UKR] З найкращими побажаннями Anton Gladkyy 2009/6/23 Mohammad Nurul Islam nisla...@yahoo.com Hi, Preparation of YADE documentation will be a good step for new users.I have some own documentation that I have prepared with respect to PFC and OVAL and some other open source DEM code, manual. And I guess other YADE users also have such types of documentation.If we share each others documentations, it will enrich YADE resource. Ofcourse there are some documentation on YADE, but for new users it is questionable, how much it will be helpful !!! Regards, Mohammad Nurul Islam --- On Tue, 6/23/09, Anton Gladky gladky.an...@gmail.com wrote: From: Anton Gladky gladky.an...@gmail.com Subject: [Yade-users] YADE documentation To: Yade Development Group yade-us...@lists.launchpad.net Date: Tuesday, June 23, 2009, 8:38 AM Hi all! I have some thoughts on YADE documentation. I am working with YADE not so much time. But the main thing, what waste a lot of time, is the insufficient documentation. I'm sure it stops a lot of new potential users and (probably) developers. So my guess is, that it would be good to start from creating short but informative instructions or howtos for different tasks. It should include short description how to do it and good examples with comments. I like style which has been used for C++ tutorial http://www.cplusplus.com/doc/tutorial/ I am ready to write some of such documents, but my YADE knowledges are yet not so deep. I think it is an important to have a good and easy-understandable documentation. __ [ENG] Best Regards [GER] Mit freundlichen Grüßen [RUS] С наилучшими пожеланиями [UKR] З найкращими побажаннями Anton Gladkyy -Inline Attachment Follows- ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-us...@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-us...@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-us...@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] Questions on contact logic and the new requestErase approach
Hello
I saw (perhaps not so) recent changes in the contact logic (in
CohesiveFrictionalContactLaw), and I'm not sure it is correct.
I started writing an email then I found a message from Vaclav about
this. I'm reviewing Vaclav's message and sending another mail when its done.
The text below is a before-review version, just for history...
Bruno
If I understand correctly, we have :
1. Previous approach :
The contact law set !isReal when there is no physical interraction.
If (!isReal !AABBintersection) _at the end of the cycle_, then erase
interaction.
2. Current approach :
The contact law request deleting interaction at the beginning of next
iteration as soon as there is no physical interraction.
CohesiveFrictionalContactLaw, l.122 :
{ // BREAK due to tension
ncb-interactions-requestErase(contact-getId1(),contact-getId2());
But then, if AABBs still overlap, the collider will immediatly create
the same iteration again, which is a waste of time.
Or, even worst, it might be possible that the collider will keep this
interaction deleted (IIRC the collider only detects BBs changing status
from !overlap to overlap, when BBs keep overlaping, it does nothing). So
if the same bodies come in contact again, the contact will not be
detected at all.
Also, I still see in the collider :
if(!overlap found (haveDistantTransient ? !interaction-isReal() :
true) ){
//LOG_DEBUG(Erasing interaction #id1=#id2
(isReal=interaction-isReal));
transientInteractions-erase(body_id_t(id1),body_id_t(id2));
Which means we are deleting interactions twice if
(haveDistantTransient), or perhaps never, since the contact law is not
setting isReal=false anymore.
O
--
___
Chareyre Bruno
Maitre de conference
Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : 33 4 56 52 86 21
Fax : 33 4 76 82 70 43
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] YADE documentation
The idea behind my proposal is to design a new structure for yade documentation. I know also that the current wiki contains a large quantity of documentation thanks to contributors. But honestly it is not very easy to find some information (this is NOT a criticism because I am very pleased to be able to access the informations contained in the wiki). So I began this adventure in the hope that WE will find a nice design. Here is a draft proposal of the doc structure: http://yade.wikidot.com VR Le 24 juin 09 à 13:38, Anton Gladky a écrit : As for me it is no differences where Yade documentation will be placed. The main is to have the articles. So if you find wikidot.com better - no problem. We just need to place links from yade.wikia.com and define which documentation will be in yade.wikia.com and which one will be in wikidot.com. PS Actually, in a future it is good to have 1 website with all YADE stuff. PPS domain name yade.info is available __ [ENG] Best Regards [GER] Mit freundlichen Grüßen [RUS] С наилучшими пожеланиями [UKR] З найкращими побажаннями Anton Gladkyy 2009/6/24 Vincent Richefeu riche...@geo.hmg.inpg.fr Hi, If no objection, I propose to create a second wiki (on wikidot.com) exclusively dedicated to yade documentation. I personally use wikidot and I find it much more user-friend than wikia. I could design and propose (in a first stage) a structure for the site. Then, any contributor will be able to add pages. In worst cases, the second wiki may be deleted. Please give me your opinion about this solution, VR Le 24 juin 09 à 10:24, Anton Gladky a écrit : I think if we have as more documents as possible will be positive for new users. We can start from creating pages on wiki and then we'll see how it is better to structure in one document. __ [ENG] Best Regards [GER] Mit freundlichen Grüßen [RUS] С наилучшими пожеланиями [UKR] З найкращими побажаннями Anton Gladkyy 2009/6/23 Mohammad Nurul Islam nisla...@yahoo.com Hi, Preparation of YADE documentation will be a good step for new users.I have some own documentation that I have prepared with respect to PFC and OVAL and some other open source DEM code, manual. And I guess other YADE users also have such types of documentation.If we share each others documentations, it will enrich YADE resource. Ofcourse there are some documentation on YADE, but for new users it is questionable, how much it will be helpful !!! Regards, Mohammad Nurul Islam --- On Tue, 6/23/09, Anton Gladky gladky.an...@gmail.com wrote: From: Anton Gladky gladky.an...@gmail.com Subject: [Yade-users] YADE documentation To: Yade Development Group yade-us...@lists.launchpad.net Date: Tuesday, June 23, 2009, 8:38 AM Hi all! I have some thoughts on YADE documentation. I am working with YADE not so much time. But the main thing, what waste a lot of time, is the insufficient documentation. I'm sure it stops a lot of new potential users and (probably) developers. So my guess is, that it would be good to start from creating short but informative instructions or howtos for different tasks. It should include short description how to do it and good examples with comments. I like style which has been used for C++ tutorial http://www.cplusplus.com/doc/tutorial/ I am ready to write some of such documents, but my YADE knowledges are yet not so deep. I think it is an important to have a good and easy-understandable documentation. ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-us...@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] [svn] r1813 - in trunk/pkg/dem: . Engine/DeusExMachina Engine/StandAloneEngine PreProcessor
Author: chareyre
Date: 2009-06-24 19:04:39 +0200 (Wed, 24 Jun 2009)
New Revision: 1813
Added:
trunk/pkg/dem/Engine/DeusExMachina/SampleCapillaryPressureEngine.cpp
trunk/pkg/dem/Engine/DeusExMachina/SampleCapillaryPressureEngine.hpp
Modified:
trunk/pkg/dem/Engine/DeusExMachina/CapillaryStressRecorder.cpp
trunk/pkg/dem/Engine/DeusExMachina/ContactStressRecorder.cpp
trunk/pkg/dem/Engine/StandAloneEngine/CapillaryCohesiveLaw.cpp
trunk/pkg/dem/PreProcessor/TriaxialTestWater.cpp
trunk/pkg/dem/SConscript
Log:
1. Update capillary files and add a new engine for them.
2. Prepare for removing old useless classes (typically some variants of engines
with water at the end)
Modified: trunk/pkg/dem/Engine/DeusExMachina/CapillaryStressRecorder.cpp
===
--- trunk/pkg/dem/Engine/DeusExMachina/CapillaryStressRecorder.cpp
2009-06-24 16:28:58 UTC (rev 1812)
+++ trunk/pkg/dem/Engine/DeusExMachina/CapillaryStressRecorder.cpp
2009-06-24 17:04:39 UTC (rev 1813)
@@ -43,7 +43,10 @@
{
if(deserializing)
{
- ofile.open(outputFile.c_str());
+ //bool file_exists = std::ifstream (outputFile.c_str()); //if
file does not exist, we will write colums titles
+ ofile.open(outputFile.c_str(), std::ios::app);
+ //if (!file_exists) ofileiteration s11 s22 s33 e11 e22 e33
unb_force porosity kineticE endl;
+
}
}
Modified: trunk/pkg/dem/Engine/DeusExMachina/ContactStressRecorder.cpp
===
--- trunk/pkg/dem/Engine/DeusExMachina/ContactStressRecorder.cpp
2009-06-24 16:28:58 UTC (rev 1812)
+++ trunk/pkg/dem/Engine/DeusExMachina/ContactStressRecorder.cpp
2009-06-24 17:04:39 UTC (rev 1813)
@@ -9,6 +9,7 @@
#include ContactStressRecorder.hpp
#include yade/pkg-common/RigidBodyParameters.hpp
#include yade/pkg-common/ParticleParameters.hpp
+//#include yade/pkg-common/Force.hpp
#include yade/pkg-common/Sphere.hpp
#include yade/pkg-dem/BodyMacroParameters.hpp
#include yade/pkg-dem/ElasticContactLaw.hpp
@@ -22,35 +23,34 @@
#include yade/core/MetaBody.hpp
#include boost/lexical_cast.hpp
-CREATE_LOGGER(ContactStressRecorder);
+CREATE_LOGGER ( ContactStressRecorder );
-ContactStressRecorder::ContactStressRecorder () : DataRecorder()
-
+ContactStressRecorder::ContactStressRecorder () : DataRecorder()/*,
actionForce ( new Force )*/
{
outputFile = ;
interval = 1;
-
+
height = 0;
width = 0;
depth = 0;
thickness = 0;
- upperCorner = Vector3r(0,0,0);
- lowerCorner = Vector3r(0,0,0);
-
- sphere_ptr = shared_ptrGeometricalModel (new Sphere);
+ upperCorner = Vector3r ( 0,0,0 );
+ lowerCorner = Vector3r ( 0,0,0 );
+
+ sphere_ptr = shared_ptrGeometricalModel ( new Sphere );
SpheresClassIndex = sphere_ptr-getClassIndex();
-
+
//triaxCompEng = NULL;
//sampleCapPressEng = new SampleCapillaryPressureEngine;
-
+
}
-void ContactStressRecorder::postProcessAttributes(bool deserializing)
+void ContactStressRecorder::postProcessAttributes ( bool deserializing )
{
- if(deserializing)
+ if ( deserializing )
{
- ofile.open(outputFile.c_str());
+ ofile.open ( outputFile.c_str() );
}
}
@@ -58,36 +58,36 @@
void ContactStressRecorder::registerAttributes()
{
DataRecorder::registerAttributes();
- REGISTER_ATTRIBUTE(outputFile);
- REGISTER_ATTRIBUTE(interval);
-
- REGISTER_ATTRIBUTE(wall_bottom_id);
- REGISTER_ATTRIBUTE(wall_top_id);
- REGISTER_ATTRIBUTE(wall_left_id);
- REGISTER_ATTRIBUTE(wall_right_id);
- REGISTER_ATTRIBUTE(wall_front_id);
- REGISTER_ATTRIBUTE(wall_back_id);
-
- REGISTER_ATTRIBUTE(height);
- REGISTER_ATTRIBUTE(width);
- REGISTER_ATTRIBUTE(depth);
- REGISTER_ATTRIBUTE(thickness);
- REGISTER_ATTRIBUTE(upperCorner);
- REGISTER_ATTRIBUTE(lowerCorner);
+ REGISTER_ATTRIBUTE ( outputFile );
+ REGISTER_ATTRIBUTE ( interval );
+ REGISTER_ATTRIBUTE ( wall_bottom_id );
+ REGISTER_ATTRIBUTE ( wall_top_id );
+ REGISTER_ATTRIBUTE ( wall_left_id );
+ REGISTER_ATTRIBUTE ( wall_right_id );
+ REGISTER_ATTRIBUTE ( wall_front_id );
+ REGISTER_ATTRIBUTE ( wall_back_id );
+
+ REGISTER_ATTRIBUTE ( height );
+ REGISTER_ATTRIBUTE ( width );
+ REGISTER_ATTRIBUTE ( depth );
+ REGISTER_ATTRIBUTE ( thickness );
+ REGISTER_ATTRIBUTE ( upperCorner );
+ REGISTER_ATTRIBUTE ( lowerCorner );
+
}
bool ContactStressRecorder::isActivated()
{
- return ((Omega::instance().getCurrentIteration() % interval == 0)
(ofile));
+ return ( ( Omega::instance().getCurrentIteration() % interval == 0 )
( ofile ) );
}
-void
Re: [Yade-dev] contact login yet again
Just one question : does it means all interaction laws (even not distant, like dry friction) have to request deletion now? Bruno Václav Šmilauer a écrit : In last few months I had suspicious problems of bodies that obviously didn't interact even when physically overlapping (one going through another). As a result of me writing from scratch InsertionSortCollider, thinking that PersistentSAPCollider might be wrongly detecting contacts, I have the following conclusions for interactions: 1. Some colliders (jsut 2: InsertionSort and PersistentSAP, which uses the same algo but is slower ;-) ) only see interactions when either the AABB's didn't overlap in last step and now do, or the other way (inversion in the ordering, using the computing terminology). 2. For non-cohesive interactions (those that should exist only if there is overlap of bodies, therefore of AABBs), we used to delete interaction by saying I-isReal=false. That returns the interaction back to potential state, as the collider will set I-isNew=true. If there is again real overlap, the InterGeom and InterPhys functors will create the interaction again. If there is no overlap, the collider will delete the interaction for good at the point the AABBs don't overlap anymore. 3. For cohesive (that is, possibly distant) interactions, this doesn't work anymore. Suppose a constitutive law wants to delete an interaction when normal elongation of the contact exceeds some positive value (think tensile damage). If you use I-isReal=false, then the interaction falls to the potential state. Now: if the AABBs don't overlap at this point anymore, the interaction will be in the potential state possibly forever, since the collider will never see such interaction again, as the AABBs have already separated _before_ the contact was marked isReal=false. This slows down the computation by keeping useless interactions around. (PersistentSAPCollider has an extra loop over interactions, that detects such cases; but it slows down). 4. If I set I-isReal=false, it doens't follow that the collider will also set I-isNew=true, as it will not see the interaction unless AABBs enter/quit the overlap. I-isNew is NOT always equal to (bool)I-interactionPhysics or (bool)I-interactionGeometry: a once existing interaction, after setting I-isReal=false, will still have I-isNew=false. If geometry/physics functor sees such interaction, it will only UPDATE (not create a new) geometry and physics for the interactions, i.e. using values of internal variables from the interaction before! The solution I created is to hint the collider that an interaction is not needed anymoer and let it decide whether to really erase it or what else to do. Instead of saying I-isReal=false, you call interactions-requestErase(id1,id2) and the collider will, at the next step, look at the pair; if there is still AABB overlap, the interaction is kept as potential; if there is no AABB overlap anymore, it will delete the interaction for good. Then the list of interactions to delete is cleared. (this solves point 3.) Moreover, interactions-requestErase will call Interaction::reset() which will make sure that interactionGeometry, interactionPhysics, isReal, isNew, ... are reset to the initial state of an interaction that was never real. (this solves point 4.) (At this point, I think we are ready to remove haveDistantTransient flag from the colldiers.) I will try to go through the code to erradicate all occurences of isReal=false and such. Maybe we better get rid of isNew as well, instead of having to keep it in sync with (bool)I-interactionPhysics and (bool) I-interactionGeometry all the time? Best regards, Vaclav ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp -- ___ Chareyre Bruno Maitre de conference Grenoble INP Laboratoire 3SR - bureau E145 BP 53 - 38041, Grenoble cedex 9 - France Tél : 33 4 56 52 86 21 Fax : 33 4 76 82 70 43 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
