원래는 궤도계산을 기반으로하는 운영 시뮬레이션 게임을 만들고자 하였기 때문에
Satellite Operator 라는 이름으로 시작하였으나,
7월 내내 개발해본 결과,
실질적으로는 Flight Dynamics Engine에 관한 부분만을 개발 중에 있음.
그래서 네임스페이스 이름을 Hut.FDS로 변경.
구체적으로는 지난주 중순 이후에 확 경각심이 느껴져서, 얼른 개발하고 치우자는 쪽으로 전환중.
초기 Coordinates 관련 개발을 수행할 때에는 다음과 같이 Matrix, Vector 쪽이 문제였는데,
개발이 진행될 수록 계산관련 부분보다는 구조적 문제가 더 눈에 들어옴.
1. Matrix, Vector 타입과 Coordinate 타입 간의 형변환 문제.
궤도계산을 하여야 하므로 주로 사용하게 되는 구조체가 Cartesian Coordinate이고,연산 대부분은 vector, matrix를 사용하게 되므로, 해당 타입에 대한 형변환이 자연스럽게 이루어지도록 하였음.
MathNet에서 Matrix, Vector 타입이 static이고, 상당히 추상화되어 있는 클래스라서, 상속받아서 해결이 불가능한 상황.
그렇다고 매번 Vector<Double>.Build.Dense(6) 해주면서 캐스팅해 줄 수는 없는 노릇이라, (너무 길어)
해당 부분에 대해서는 MathNetExtensions 에서 각 Build 함수를 Func<int, Vector<double>>. 형태로 매핑하여 해결.
덧붙여 Coordinate 타입 및 Vector 타입간의 기본적인 사칙연산에 대한 operator 작성.
아무래도 이 부분 없으면 너무 불편해짐..
2. 연산 중간에 수없이 존재하는 배열-기반 초기화(coefficients) 관련.
C# 12에서 제공하는 List/Array 초기화 연산자 [] 로 대체하고, 해당 리스트/배열로부터 Vector<double> 타입을 받아오는 ArrayToVector, ListToVector 확장 작성. 이를 다시 래핑하여 FromArray 확장 작성.
기본적인 배열 초기화는 대부분 [] 를 이용하도록 하였음.
3. 슬라이딩 윈도우 관련하여, 범위지정을 통한 슬라이딩 enumerator 확장
종종 계산 중 (prev, curr, next) 형태로 계산되어야 하는 것들이 있는데, 예전 코드야 indexer 범위를 조정해가면서 했다지만, foreach enumeration 적용이 안 되니까 이걸 좀 더 확장가능하게 적용. (-1,1) 이면 -1~1 범위를 갖는 윈도우를 상정함.
여기까지가 초반 문제였고, Coordinate 관련 타입을 정의하느라 생기는 문제이기도 하고,
코드 자체를 줄인다는 목적으로 변경하였기 때문에 꽤나 기계적이었음.
근데 진짜 문제는 여기서부터.
4. 공통 프로세스 정의
이전부터 이 프로그램의 가장 큰 문제점은 Determination/Prediction/Maneuver/EventPrediction/Colocation 각 프로그램에서 사용하는 Setup파일이 서로 상이하다는 점임.
물론 수행되는 프로세스가 다르니까 다른 이유는 납득이 가는데, 이걸 하나의 시스템으로 묶어서 처리하려다 보니까 Station, Satellite(Spacecraft), Maneuver, Database 등을 모두 Setup 파일에 의존하게 되어버리는 데다가,
사용자가 매번 이 Setup파일을 손으로 작성해야 된다는 점은 매우 큰 패널티임.
따라서 이 부분을 자동화하여, Setup 자체를 경량화시키는 데 목적을 두고, Input파일(혹은 설정)으로부터 일반화된 파이프라인을 구성
Start->Initialize->Configuration->Setup->Work->Program
순으로 처리되도록 프로세스를 정의하고,
Initialize 부분에서 Input, Profile(environment)를 확인하며,
Configuration에서는 Input에 따라 데이터들을 읽고 초기화,
각각의 Input으로부터 작업(Work)을 정의하고, WorkList.Run()을 통해 Program(Setup, Profile) 작업 수행.
이 과정에서 특히 Spacecraft, Station, Maneuver 등의 정보를 Input에서 지정해 줌으로써, Setup의 사용자 작성부분을 줄일 수 있음.
(물론 각 프로그램별로 Option이 다르기 때문에, 완전 대체는 조금 어려울 것 같긴 함.)
여기서 시간 겁내 뺏기는 중
5. 전역 변수 및 보조 기능의 처리
전역 변수 정의나, 설정, 세팅 등의 값이 제각각임. 일단 이런 부분을 통일.
이와 관련해서 Potential과 Acceleration 부분이 있는데, 각 상황에 따라 사용하는 초기값이 다름;;
이걸 Configuration 부분에서 선택적으로 해결하도록 변경하고,
전역변수나 상수에 대한 부분들도 최대한 중복을 제거.
보조(Auxiliary) 기능의 경우, 대부분 출력이긴 한데(크게 중요하지 않음.) 가끔 계산과 관련하여 소소하거나 간략화된 메서드를 제공하는 보조적 기능들을 제공. 시간, 모델, 궤도계산 등도 약식으로 제공하기 때문에, 신중하게 중복을 제거하고 정리하여야 함.
6. 기타
Stream 출력 및 Console 출력이 섞여 있기도 하고, 함수 중복도 심각하고, Ephemeris 출력과 관련된 Information Record 부분도 공통적으로 사용됨. 실제 해당 부분들을 확인하고 조금씩 대체하면서 제거해야 하겠는데, 이게 또 완벽하게 맞는게 아니다 보니까 딱 그거다 하고 대체하기가 좀 힘든 감이 있음.
전반적인 네임스페이스 정의에 대해서 다시한번 고민 중.
암튼 삽질에 삽질을 거듭하고 맥북을 불태워가면서 개발중에 있음.
7월 중에 Setup 생성까지 완료된 상태만 되더라도 이후는 쉬워질 것 같다.
