Index: sm/trunk/todo
===================================================================
--- /issm/trunk/todo	(revision 7487)
+++ 	(revision )
@@ -1,114 +1,0 @@
-Create sorting routine for ids.
-Update all inputs. Look at that in more details, ie with respect to control methods. When do we do update of inputs?  Handle input update for Nodes and Materials. 
-Define default cluster in /etc/cielo.rc
-VelocityExtrude: debug 
-FindParam(vx) then DeleteParam("vx")? Should vx be a Vec? Can we find a way of partionting vx with partition, and staying in parallel?
-Update control to get new inputs, as well as parallel diagnostic
-
-Finish diagnostic_core.m
-Create sorting routine for ids.
-WriteData for OutputDiagnostic
-OutputDiagnostic not working in 3d. (wrong gsize)
-Finish thermal.m solution, and thermal.cpp solutoin. bukld thermal element.
-Check that gaussian points get erased everywhere!
-Check that GetJacobianDeterminant is computed correctly. 
-Lighten up on parameters when they have been used.
-Create new framework for outputing parallel results.
-
-
-Look at: 
-ProcessParamsx
-OutputThermal
-CreateFemModel
-Dakota patch
-Finish root, suffix, isnumeric in shared/String. Then, do partition recover in SpawnCore.
-
-ismodelresultsconsistent: do it with results field now. suppress vx,vy,vz,vel,temperature,melting,transient_results, etc ...
-lighten up the parameters, make a routine.
-check that ismodelselfconsistent checks concurrency is 0 when running in parallel!
-Fix problem that dakota does not MPI_Finalize correctly! 
-only min_vel is processed!
-Make sure inputs are updated homogeneously: ex: if updating thickness, surface and bed also need to be updated! this could get complicated, for 
-ex, if an object depends only on surface, but thickness gets updated, then the object should still pick up the surface change (if on a bedrock for example).think 
-about that quite hard.
-Debug Dakota new code. Then think about systemtizing ModelProcessor! It's getting out of hands + lighten up on parameters! 
-Write qmu doc, change names may be?
-
-Answer Jesse, Bob.
-
-
-
-
-
-
-
-Look at issm_options.m4, homogeneize! 
-Look at petsc, why doesn't it compile?
-Homogeneize the archive.
-
-
-
-
-
-
-
-Look at issm_options.m4, homogeneize! 
-Look at petsc, why doesn't it compile?
-Homogeneize the archive.
-
-
-
-
-
-
-
-Look at issm_options.m4, homogeneize! 
-Look at petsc, why doesn't it compile?
-Homogeneize the archive.
-
-
-
-
-
-
-
-Look at issm_options.m4, homogeneize! 
-Look at petsc, why doesn't it compile?
-Homogeneize the archive.
-
-
-Dakota: put misfit in: DakotaResponses is ok But now, we need parameters fit and u_g_obs put in in QmuCreateParameters. Then Misfitx in DakotaResponses should be ok.
-
-
-Get Matlab 7.8: version 4.2.3
-Use gprof to figure out where we are losing out time. 
-test
-
-test commit
-test2
-
-
-
-
-transfer slope computation scripts in serial, to reflect new scripts in parallel.  
-md=solve(md,'SolutionType','DiagnosticSolutionEnum'); instead of md=solve(md,'AnalysisType','DiagnosticSolutionEnum');  do the work of transferring
-
-
-
-melting_offset needs to go into the inputs in the thermal solver.  activate correct analyses in cores.
-
-Check, but I'am pretty sure Dux generates du_g on 4 dofs in stokes, but writes only 2 dofs at a time, ie, writes over 
-Vz and Pressure dofs in the Tria Du routine coming from a Penta Spawn.
-
-
-
-OutputResults: more complex, with time and step
-FlagClones: fix that using the sid.
-
-
-Sensitivities:  
-%do test decks for MassFlux and Misfit validation. 
-%do process_units so MassFlux is in the correct unit.
-
-
-
