pp

Post/ColorTable.cpp

-// $Id: ColorTable.cpp,v 1.1 2007-07-09 13:54:37 geuzaine Exp $
+// $Id: ColorTable.cpp,v 1.2 2007-09-13 06:31:37 geuzaine Exp $
 //
 // Copyright (C) 1997-2007 C. Geuzaine, J.-F. Remacle
 //

Post/ColorTable.h

@@ -35,7 +35,7 @@ typedef struct{
 #define COLORTABLE_RGB  1
 #define COLORTABLE_HSV  2
 
-// integrer parameters indices
+// integer parameters indices
 
 #define COLORTABLE_NUMBER    0  // predefined curve index
 #define COLORTABLE_INVERT    1  // invert (rbg<->255-rgb)

Post/PViewDataGModel.cpp

-// $Id: PViewDataGModel.cpp,v 1.3 2007-09-08 21:26:05 geuzaine Exp $
+// $Id: PViewDataGModel.cpp,v 1.4 2007-09-13 06:31:37 geuzaine Exp $
 //
 // Copyright (C) 1997-2007 C. Geuzaine, J.-F. Remacle
 //
@@ -24,6 +24,49 @@
 
 #include "PViewDataGModel.h"
 
+/*
+add new optional field in .msh file to store
+
+- node or element post-pro data
+- one field per-time step, per view
+
+$Data
+name precision-single-double step time-value
+type node-or-ele-id num-comp val (num-comp times)
+type node-or-ele-id num-comp val (num-comp times)
+...
+$EndData
+
+Then?
+
+1) in MVertex and MElement, add
+
+std::vector<std::vector<double> > _scalar, _vector, _tensor;
+
+and access using e.g. _scalar[viewIndex][comp & time step]. In GModel
+we would store a map with the correspondance between the index and the
+unique view id created in PView().
+
+2) Or, we store directly a map indexed with the unique view id
+
+1) and 2) are pretty expensive, due to the overhead and the "micro"
+allocations (in each element/node)
+
+3) It might be better to store the data *per entity*?
+
+4) Or just store the big vectors in the GModel?
+
+My preference at the moment is to store per entity (i.e., (3)): not
+too much overhead; can do local indexing and checks with
+nodes/elements--which are stored per entity too; avoids storing entity
+ptr in each value (I think we should have that info in the post-pro:
+it's one of the annoying shortcomings of the old format)
+
+f we choose 3, unfortunately, we need to keep track of some local
+indices to access the data with a single, continuous index. This is
+exactly the same problem as with PViewDataList. Maybe it's worth it?
+*/
+
 bool PViewDataGModel::writePOS(std::string name, bool binary, bool parsed,
 			       bool append)
 {