Replace PackedFactor convert functions with specific function. Two chicken and egg problems, unpack DFGFactor

[dehann]

We should NOT use driving assumption that Base.convert API is right way to hydrate DFGFactor (which currently internally rebuilds operational data like CCW).

IncrementalInference.jl/src/DispatchPackedConversions.jl

Lines 33 to 55 in 88c0cb4

	function convert(
	::Type{GenericFunctionNodeData{CommonConvWrapper{F}}},
	packed::GenericFunctionNodeData{P} ) where {F <: AbstractFactor, P <: PackedInferenceType}
	#
	# TODO store threadmodel=MutliThreaded,SingleThreaded in persistence layer
	usrfnc = convert(F, packed.fnc)
	mhcat, nh = parseusermultihypo(packed.multihypo, packed.nullhypo)
	# TODO -- improve _prepCCW for hypotheses and certainhypo field recovery when deserializing
	# reconstitute from stored data
	# FIXME, add threadmodel=threadmodel
	# FIXME https://github.com/JuliaRobotics/DistributedFactorGraphs.jl/issues/590#issuecomment-776838053
	# FIXME dont know what manifolds to use in ccw
	ccw = _prepCCW(DFG.DFGVariable[], usrfnc, multihypo=mhcat, nullhypo=nh, inflation=packed.inflation)
	ccw.certainhypo = packed.certainhypo
	# CommonConvWrapper{typeof(usrfnc)}
	ret = FunctionNodeData{typeof(ccw)}(packed.eliminated, packed.potentialused, packed.edgeIDs, ccw,
	packed.multihypo, packed.certainhypo, packed.nullhypo,
	packed.solveInProgress, packed.inflation )
	#
	return ret
	end

By assuming empty array DFGVariable[] we create two chicken egg problems:

• recursion on delete / add new factor but requiring a rebuild metadata in both:
  

  IncrementalInference.jl/src/DispatchPackedConversions.jl

  Line 87 in 88c0cb4

  factor_ = if typeof(fnd_new) != typeof(getSolverData(factor))

• Solver needs needs to then replace the skeleton CCW metadata type when the variable types are more easily known:
  

  IncrementalInference.jl/src/FactorGraph.jl

  Line 681 in 88c0cb4

  return FunctionNodeData{typeof(ccw)}(eliminated, potentialused, edgeIDs, ccw, multihypo, ccw.certainhypo, nullhypo, solveInProgress, inflation)

The assumption that we can hydrate a factor in a vacuum is false, we do need the connected DFGVariable type information. DFGVariable can however be hydrated in a vacuum.

[GearsAD]

Fix this when fixing JuliaRobotics/DistributedFactorGraphs.jl#590

[dehann]

we need to maintain the list of exceptions to DFG driver symmetries. In this case, the exception is:

• rebuildFactorMetadata / OperationalMem is not required in all DFG drivers.
  • CDDFG supporting direct convolution and product operations is Tier 2 requirement at best (symmetry is important, but FactorOperationalMemory is needed and only exists in LightDFG).

[sam-globus]

Yep,

LightDFG is our DFG for solving - it's optimized for this.

CGDFG and FileDFG (and ZmqDFG/GraphQLDFG, etc.) are all designed to get data from somewhere and put it into a LightDFG, and then transport solved data back into their respective destination. Those aren't built for solving/etc, to the point that ideally we don't rebuild the factor metadata.

[dehann]

Added to High Level Req Wiki: https://github.com/JuliaRobotics/Caesar.jl/wiki/High-Level-Requirements