New structure of object routines

There is now a function that can apply a second function to the 'grid'. For example: 

  SUBROUTINE ProblemGridInit(Info)
    TYPE(InfoDef) :: Info
    CALL ApplyFunction(myclump, Info)
  END SUBROUTINE

  SUBROUTINE myclump(pos, t, dt, q, Ghost)
    REAL(KIND=qPREC), DIMENSION(:) :: pos
    REAL(KIND=qPREC), DIMENSION(:) :: q
    REAL(KIND=qPREC) :: t, dt
    LOGICAL :: Ghost
    dq=0
    IF (sum(pos**2) <= 1d0) THEN
       q(1)=10d0
    END IF
  END SUBROUTINE myclump

If you want to smooth your solution into a background state - then provided that 'q' comes in with a background state, you can just modify the function 

  f = smoothing_function(pos)
  q(1)=(1-f)*q(1)+f*10d0

Existing objects can use the same routine - as long as the object type can be sent to the function. This is tricky to do in fortran - but is possible by casting the 'Outflow' or 'Clump' object as an 'Object' 

  SUBROUTINE OutflowBeforeStep(Info, Outflow)
    TYPE(InfoDef) :: Info
    TYPE(OutflowDef), POINTER :: Outflow
    TYPE(ObjectDef), POINTER :: Object
    CALL TransferOutflowToObject(Outflow, Object)
    CALL ApplyFunction(OutflowSource, Info, IEVERYWHERE, lHydroPeriodic, Outflow%shape, Object)
  END SUBROUTINE OutflowBeforeStep

  SUBROUTINE OutflowSource(pos, t, dt, q, Ghost, object)
    REAL(KIND=qPrec), DIMENSION(:) :: pos,q, dq
    REAL(KIND=qPREC) :: t, dt
    LOGICAL :: Ghost
    TYPE(ObjectDef), POINTER :: Object
    TYPE(OutflowDef), POINTER :: Outflow
    REAL(KIND=qPREC) :: density, velocity, energy

    CALL TransferObjectToOutflow(Object, outflow)
    q(1)=Outflow%density
   ...

Now most objects have shapes that have routines that help transfer coordinates into the shapes orientation etc… But vectors also need to be rotated into and out of the shapes orientation. The momentum (and Magnetic) vectors need all 3 components to properly do the transforms - even if nDim==2. Since q does not always have all 3 components of velocity, this is a minor problem. One solution is to temporarily insert additional components of momentum into the q array. The routines that set the values for 'q' would need to explicitly use q(/ivx,ivy,ivz/) to access the momentum - and can no longer assume that the components of momentum are contiguous. The other option is to keep the routines that transform objects into a shapes reference inside the final function.

The other issue is what form of the fluid variables are stored in 'q'. Primitive is the easiest for the user to code.

Comments

No comments.