Dymaxion.Kim

2017년 1월 19일 목요일

블로그 이사 공지

저의 개인 블로그는 이곳으로 이사했습니다.

https://dymaxionkim.github.io/beautiful-jekyll/

DymaxionKim

Mechanical & Robotics Designer

dymaxionkim.github.io

2016년 6월 29일 수요일

2016년 4월 20일 수요일

이거 전형적인 '한국형 기업 문화'의 형태라는건 다들 잘 아실것 같아요.
경험적으로 보면 회사 내부 사정이 이런 식으로 돌아가면 대체로 이렇게 흘러가던데...

1단계
경영진이 매출/성과 가시화에 대한 압박으로 불가능한 목표 + 무리한 일정을 요구한다.

2단계
말솜씨가 좀 없고 진짜 핵심적인 엔지니어가 중역에게 '이런식으로는 안됩니다' 했다가 엄청 모욕만 받고 찌그러진다. 사장은 웬 어리버리한 듣보잡이 되도 않은 소리하냐고 중역에게 질책한다(사장은 누가 진짜 핵심 개발자인지 잘 모른다).

3단계
엔지니어링 능력은 좀 떨어지지만 사내정치에 능한 타입의 PM이 핵심 엔지니어를 왕따시킨다.

4단계
이때 2가지 경우로 분기가 됩니다.

    핵심 엔지니어가 관둔다.
    핵심 엔지니어가 자신의 수명과 프로젝트를 맞바꾸기고 결심하고 스팀팩을 맞고 어떻게든 계속한다.

5단계
핵심 엔지니어가 관뒀을 경우에는, 그대로 프로젝트가 망한다. 계속 이어지는 것 처럼 보여도 결국 망하게 되어 있다.
핵심 엔지니어가 어떻게든 구현은 해낸다. 물론 올바른 소프트웨어공학을 적용할 수 있는 상황이 아니었으므로 구현하는데만 급급할 수 밖에 없어서, 버그를 예측할 수 없고 또 버그가 나와도 구조적으로 해결하기 곤란한 경우가 많다. 화면이 나간다던가, 블루스크린이 뜬다던가 하는 눈에 확 띄는 버그가 나오게 되면 사내 품평회에서 사장 및 중역들은 핵심 개발자를 불러다가 실력이 없다는 둥 별 모욕을 다 주고 회의식 밖으로 쫒아보낸다. PM은 핵심 개발자에게 모든 책임을 다 떠넘긴다.

6단계
경영진은 모든 것을 '엔지니어의 실력 탓'으로 돌리고, 이런 어리버리한 한 사람의 개발자에게 핵심적인 기술이 종속되는 상황은 경영학적으로 안 좋으니, 핵심 개발자가 아키텍쳐를 설계할 수 있는 권한을 다 빼앗고, 여러 명을 투입하면 더 나은 결과가 나올 거라고 믿는다.

7단계
안간힘을 쓰면서 아키텍쳐의 '우아함'을 지켜나가던 핵심개발자의 설계권한이 무시되었으므로, 그보다 실력이 한참 떨어지는 저급 개발자들이 여러명 달라붙어 소위 '입개발'을 시전한다. 아키텍쳐는 결국 누더기가 되고, 이걸 감당할 능력이 없기 때문에 입개발자들은 시간이 흘러가면서 하나 둘 조용히 퇴사한다. 물론 퇴사 이유는 다른 핑계를 댄다.

8단계 : 亡

보통 중소기업 레벨에서는 한 사람의 핵심 엔지니어에 의해 특정 프로젝트/사업의 성패가 완전히 종속되는 경우가 있죠.
이게 경영적으로는 분명 리스크 요인은 맞는데, 이걸 피하려면 제대로 된 개발시스템과 프로세스를 밟아나가야 되는데, 과정보다 결과만 중시하는 한국 특유의 문화 때문에, 이런 상황을 경영진 스스로 자초하면서 그 탓을 핵심 엔지니어에게 덮어씌우는 상황이 자주 연출됩니다.

'핵심 엔지니어'는 대체로 학구적 성향, 말솜씨가 좀 떨어지고, 사교성이 조금 덜 한 경우가 왕왕 있더군요.
(영화 이미테이션 게임에 나오는 엘런 튜링 비슷한 거라고 보면 될 듯.)

물론 요즘은 엔지니어에게 요구되는 자질이, 엔지니어링 능력 자체 보다는 사회적 스킬과 커뮤니케이션 능력, 매니지먼트 능력을 중시하는 경향이 강하긴 합니다만...
이게 과연 정답일지는 의문입니다.
아시다시피 '여러 분야에 모두 깊게 잘 하는 완벽한 엔지니어'는 잘 없습니다.
(사실 내 관점에서는 그런 사람을 단 한 명도 본 적이 없습니다.)

특히 기술적으로 도전적인 과제의 경우에는, 엔지니어링 자체에 아주 깊게 탐험해 들어가는 천재 - 사회적 멍청이형의 엔지니어가 있어야 진척이 발생하는 경우를 자주 봤습니다.
'입개발'하는 사람들만 모아놔서는 아무것도 안되죠. 그런 타입의 엔지니어들은 자기가 뭘 신기술을 도전한다던가, 아주 어려운 것을 온전히 자기 어깨에 모든 책임을 지고 몸을 던지지 않거든요.
남이 구현해 놓은 것을 보고 품평이나 하는 스타일이 많습니다.

아무튼, 티맥스의 내부 사정은 잘 모르겠지만, 프로젝트가 저따위로 기획/진행되고 완성도가 충분치 않은 상태에서 무리하게 일정이 잡혀진 발표를 강행해 버리는 것은 티맥스 회사의 경영진의 자질에서 모든 문제가 비롯된다고 봅니다.
모르긴 몰라도, 발표회장에서 컴퓨터가 얼어버리거나 다운되는 버그의 원인을 제공한 코드를 작성한, 누군지 모를 그 '핵심 엔지니어'가 그 회사 안에서 받게 될 모욕과 뒷담화를 상상하게 되네요.

'우리 회사는 쿨하니까 기술적으로 실수해도 왕따 같은거 안 시켜'

라고 말하는 사람이 있다면 한국 기업 문화의 어두운 측면을 외면하는 부류 아닐까 합니다.

2016년 4월 9일 토요일

STEP AP242 Standard

3D 설계데이타 교환을 위한 국제표준 중립 포멧으로 STEP이 제정된지 수십년이 흘렀는데, 아직 CAD 분야에서는 STEP Native Modeler는 개발되지 않았다. 그리고 현재 현업에서는 대부분 AP203 및 AP214를 사용한다.

우선 AP203에 관해서.

IGES를 대체하기 위해 STEP 표준이 논의되면서, 제일 먼저 나온 사양이 AP203이다. AP 명세를 구현하는 실체는, 텍스트로 표현된 Express 스키마 문법이다. 이때는 아직 XML이 나오기 전이므로, 전용의 구문 문법을 개발해서 사용한 것이다. AP203을 주도적으로 제정한 곳은 미국 국방분야의 항공회사들로 보통 알려져 있다. 즉 보잉 같은 회사를 말한다. 초창기 표준이므로 가벼운 대신 담고 있는 정보가 좀 부족하다. 예를 들어, 내부에 구성되어 있는 엔티티들의 색상을 정의하는 구문이 존재하지 않는다. 따라서 초창기 AP203 표준에 따라 구현된 STEP 파일 생성기로 만들어낸 STEP 파일을 CAD에서 읽어들이면, 색상정보가 다 빠져버려 탈색된 빨래 같은 것이 뜨게 된다.
물론 시대가 흐르면서 AP203도 계속 업그레이드 되었다. 따라서 요즘 사용하는 버전의 3D CAD 툴에서 생성한 AP203 STEP 파일들은 색상 정보를 담아낼 수 있다. 그리고, 어셈블리 구조를 모듈화하여 표현한 업그레이드 버전인 AP203-ed2가 거의 최종 버전인 것 같은데… 이 표준으로 생성할 경우에는 여러 CAD 시스템 간에 데이타 교환시 실패 확률이 매우 높아진다. 서로 제대로 구현하지 못했다는 이야기다.
좋은 예로, CREO 2에서 AP203-ed2로 STEP 파일을 생성한 후에, 그 파일을 CATIA V5R20에서 읽어들이면 형상 재구성에 실패한다. 때문에 STEP 버전을 낮춰서, CREO 2에서 구버전의 AP203으로 생성한 후에, 그 파일을 CATIA V5R20에서 읽어들이면 성공적인 결과를 볼 수 있다. 이런 식의 미묘함 때문에, STEP을 이용한 이기종 CAD 간의 데이타 교환시에는 가능한 구버전의 STEP 표준으로 파일을 생성하는 것이 유리하다. 물론 그 대신, STEP 파일 안에 담기는 정보는 더 적어지게 되고, 실질적으로는 IGES 수준의 형상 정보 정도만 교환하는데 만족할 수 밖에 없다.
사실 AP203 표준에는 더 많은 정보를 담아내서 교환하는데 써야 하는게 맞는데, CAD 시스템에서 제대로 지원해 주지를 못한다. 예를 들어, 어떤 부품이 Made 인지 Bought 인지를 구분해 주는 아규먼트가 AP203의 Express 스키마 구문 중에 분명히 있지만(PRODUCT 관련 구문), CREO 이든 CATIA이든 간에 이 항목을 제대로 매치시켜 STEP으로 생성해 주지 못한다. 그냥 없는 항목처럼 무시하는 것이다.
따라서 이렇게 생성된 STEP 파일을 PDM 시스템에 업로드 해서 해석하여 데이타베이스화하고자 해도, 형상 정보 이외의 이런 부가 정보들은 현실적으로 활용되지 못하게 된다. 각 CAD 시스템이 STEP 표준을 이렇게 대충 지원하는 이유는, 일반적으로 자사 전용 포멧을 고객에게 강요함으로써 시장지배력을 올리고 또 고객을 자사 솔루션에 종속시키기 위한 것으로 생각된다.

그리고 AP214에 관해서.

한편, AP214는 독일쪽 자동차 업계에서 주도하여 2000년 경에 확정되었다. 미국에 정면 대항하려는 목적도 있지 않았을까. 당연히 AP203보다 더 발전된 사양으로, 방대한 명세를 포함한 거대한 포멧이 되었다. 그러나 이기종 CAD간 호환성은 확실하게 AP203보다 확연히 떨어진다. AP214로 생성한 파일을 협력업체에 보냈을 때, 높은 확률로 "이 파일 읽어지지가 않아요"라는 전화를 받곤 한다.
내 경우엔, 이전 직장에서는 시제품 제작을 위해 목업 업체에 보낼 데이타는 AP214를 사용했다. 함께 서로 포멧을 조정한 기간을 거친 후에, 안정적으로 데이타 교환을 했기 때무에 문제가 없었다. 문제는 직장을 옮기고 다른 협력업체와 일을 하게 되자 그 새로운 회사에서 사용하는 소프트웨어가 달라졌기 때문에 자료 교환에 문제가 생긴 것이다. 결국 울며 겨자먹기로 AP203으로 포멧을 바꿀 수 밖에 없었다.
아무튼 AP214는 보다 더 많은 정보를 담아낼 수 있어 편리성은 높아졌지만, 이기종 CAD 간에 살짝 미묘하게 호환성이 떨어졌기 때문에 범용적으로 사용하기는 곤란한 점이 있었다.

AP242

마침내 AP203과 AP214를 합쳐서 AP242가 제정되었다. 그리고 그게 다시 업그레이드 되어 AP242-ed2 확정이 다 된 거나 마찬가지다. ed2로 올라가면서, 온갖 정보들을 더 많이 담게 되었다. PDM 관련한 각종 부가정보들, 부품간의 조립 구속조건, 파라메트릭 구속조건, 제조 관련 정보들, 전장 하네스 설계 정보, 히스토리 정보, 프리젠테이션을 위한 정보, 3차원 기구학 애니메이션을 위한 정보 등등. 이제까지의 전례를 봤을 때, 각 CAD 개발사들이 과연 AP242를 얼마나 적극적으로 준수해서 제대로 된 STEP 포멧 생성기를 만들어낼지 약간 의문이긴 하다. CAD 개발사들이 적극적으로 지원하지 않으면 사실상 죽은 표준이 될 공산도 크고…
아무튼 PTC사의 경우에는, 이 자료를 신뢰한다면, CREO 4에 AP242 관련 기능들이 다 구현되어 제공될 것으로 보인다. 경쟁관계에 있는 CATIA 및 UG 쪽도 앞서거니 뒷서거니 하면서 비슷한 시기에 나오지 않을까 싶다.
한가지 가정을 해 보자.
CAD 시스템에서 올바르게 AP242 표준에 맞도록 데이타를 만들어 낸다면?
그러면 오랫동안 사용자들이 원해왔던, 그리고 CAD 개발사들이 그렇게 오랫동안 방해해왔던 이기종 CAD 간의 그나마 쓸만한 자료교환이 가능해 질 것이다.
그렇게 될 경우, 특정 CAD의 Native Format을 지원하는 모듈을 별도 개발할 필요 없이, AP242만 지원하는 오픈소스 모듈만 가지고도 필요한 PDM/PLM, CAD 및 기타 관련 소프트웨어들의 구현이 될 것이고, 이것만으로도 프로페셔널한 수준의 진정한 산업표준 데이타 교환이 가능해져 제조업 효율이 좋아질 것이다.
개인적으로, 특정 CAD 솔루션에 종속된 설계환경은 벗어나야 한다고 본다. 생각해 보자.
CREO를 능숙하게 사용하는 구조설계자가 있을 경우, 이 사람은 CATIA를 사용하는 업체에 취업할 수 없다. 이 얼마나 바보같은 일인가?
CAD 소프트웨어가 본질이 아니고, 공학적 설계능력 자체가 핵심인데 그전에 엉뚱한 허들이 형성되어 있는 것이다.
또, CATIA를 쓰는 업체는 다른 CAD로 전환하거나 다종의 CAD 시스템을 운용하기가 어렵다. 인력 운용면에서도 그렇고 시스템 측면에서도 그렇다. (물론 대규모 자동차 업계 같은 데서는 이기종 CAD간의 조합이 이루어지기는 하지만, 악영향이 최소화되도록 모듈별로 철저하게 구분된 방식이라고 생각된다.)
따라서 CATIA에 종속된 제조업체는, 높은 비용을 고정적으로 강요받게 되고, 자금운용에서 경직적인 부분이 발생한다. 이것은 경영상의 위협요인이 아닐 수 없다.

대한민국의 현실

아마 정년퇴임하셨을 것으로 추측되는 이상헌 교수라는 분이 80~90년대에 걸쳐 초창기 CAD 분야에서 업적을 꽤 쌓았다고 알고 있다. 당시 이 분야에서의 화두 중의 하나였던 비다양체 위상 기하학을 다룰 수 있는 구조체를 구현한 CAD커널이 한창 개발되고 실용화 단계에 접어들 때의 이야기다. 현재는 비다양체 CAD커널은 그냥 아주 당연한 기본 특성이 되어 있다.
이상헌 교수의 경우, 자신의 연구에 펀딩만 좀 받았더라면 독자적인 CAD커널로 제대로 발전시킬 수 있었을 것이다. 왜냐면 같은 시기에 다른 나라들의 수준과 별 차이가 없었기 때문이다. 그러나 그런 장기적인 연구를 지원하는 시스템은 한국에 없었다. 사업가들의 눈에 띄지도 못했다. 이상헌 교수에게는 글로벌 경쟁에 나설 기회가 아예 주어지지 못했던 것이다.
그래서 지금의 한국은 그냥 CAD 및 PLM 분야에서 종속 국가가 되었다.
한국이 제조업 기반으로 흥한 나라라고들 하는데, 현재 상태로는 '제조업 2.0 (?)'이라던가 하는 말은 과대망상 내지는 허언증이다. 기초가 부실하다고 하는 좋은 예가 될 수 있을지 모르겠다.

2016년 4월 5일 화요일

OpenSource PLM에 관한 생각

OpenSource PLM에 관한 생각

PLM 시스템은 전통적으로 3D CAD 개발업체에서 나온 전용 솔루션을 쓰는 것이 당연하다고 생각된 시기가 있었다.
Pro/E를 쓰는 회사에서는 거기에 딸려서 붙어나오는 IntraLink 및 그보다 발전된 WindChill 같은 것을 쓰고,
CATIA는 Enovia 쓰고 뭐 이런 식으로...
간혹 해당 CAD와 붙어서 쓸 수 있는 3rd Party 솔루션도 있으나, 역시 전용인 것은 마찬가지다.

이런 전용 PLM 시스템은 거액의 도입비용 및 높은 실패위험을 감수해야 하므로
중소기업들은 그냥 없는 셈 치고 살았고
대기업들은 실무자의 고통과는 상관없이 시스템에 실무자(인간)들이 갈려들어가는 구조였다.
탁상머리 산업공학의 실패 아닌가 싶다.

최근 수년간의 동향을 보면,
특정 3D CAD에 종속되지 않는 개념의 PLM 솔루션들이 여럿 등장하고 있는데,
그와 함께 몇가지 특징들이 보인다.

(1) 웹서비스 기반 (클라우드화)
(2) 오픈소스 (커스텀 개발 가능하도록)
(3) 패키지 판매가 아닌 유지보수 서비스 판매 모델로의 전환 (서비스업화)

대표적으로 실적이 좋은 솔루션이 바로 ARAS INNOVATOR인 것 같다.
미국 MIT 출신 개발자들이 뚝딱뚝딱 만들어서 사업화 한 거라고 한다.
완성도가 높고 외국 대기업들 중에 채용한 사례가 많다.
계약을 하고, 아마존 클라우드나 MS 애저에 클라우드 서버를 개설하고, 요구조건에 맞춰 몇가지 기능 첨삭을 해서 서비스를 해 준다.
시스템 유지보수는 계약한 벤더가 알아서 해 주니 편하다.
대신 고정 비용이 들어간다.
만일 스스로 개조,유지보수할 자신이 있다면, 오픈소스이기 때문에 직접 설치해서 써도 된다.

문제는 이 녀석은 MS .Net 기반으로 개발된 거라는 점이다.
MS 윈도우 서버에서만 돌아간다.
또 (최근 버전업되어 해소된 것 같지만) 최근까지는 MS IE 브라우저에서만 이상없이 사용할 수 있다는 단점이 있었다.
아울러, 대기업 사용을 상정하다 보니 지나치게 복잡하고 거대하다.
꼭 필요한 기능이 많이 빠져 있어서, 이걸 집어넣으면 건건마다 비용이 발생한다.

간단히 말해 이름만 오픈소스고, 실무에 실제로 쓰려면 그냥 상용 솔루션이라고 봐도 무방하다.

이런 솔루션조차 부담스럽다면 진짜 오픈소스를 찾아야 할 것이다.

제일 눈에 띄는게 2가지였다.

(1) OpenPLM
(2) DocDoku

이중에 OenPLM은 파이선 쟝고(python Django) 웹프레임웍으로 개발된 것이다.
가장 해커스럽다고 할 만 하다.
구성에 필요한 유틸리티들은 전부 오픈소스를 끌어다 만들었다.
그런데도 의외로 상당히 강력하다.
VirtualBox로 패키지화된 것을 받아다가 바로 실행시켜 이것저것 사용해 봤더니 상당히 좋다.

가벼워서 반응이 상당히 빠르고,
3D STEP 어셈블리 파일을 업로드했더니 그걸 자기가 처리해서
곧바로 BOM까지 만들어준다.
전체 어셈블된 3D 모델 및 그 구성부품들 각각을 별도로 3D로 볼 수도 있다.
PDF로 된 도면은 각 파트마다 따로 업로드해 줬더니 웹브라우저에서 바로 열람이 가능하다.

부품번호를 자동으로 매겨주는 로직을 자사 규정에 맞게 고친다던가 하려면
소스코드를 좀 손봐야 하겠지만, 파이썬 쟝고 개발자가 만약 있다면 별로 어렵지 않다고 생각된다.

문제는 이 솔루션은 현재 개발이 버전 2.0에서 중단되었다는 점이다.
따라서 지속적인 향상은 기대하기 어렵다.

한편, DocDoku는 기존의 OpenPLM보다 좀 더 진보된 모습을 보여준다.
더 성숙된 JavaEE 기반으로 된 웹서버로 구성된다.
또 더욱 최신 웹기술이 대거 적용되어 있다.
화면도 깔끔한 디자인이다.
기능도 더 많은 것 같다.
사업화도 나름 잘 되고 있는 것 같으므로 개발이 갑자기 중단되거나 할 것 같지는 않다.

문제는, 서버 구성이 꽤 어려워 보인다.
내가 직접 하기는 좀 부담스럽다.
직업적인 자바 서버 개발자나 관리자라면 가능하지 않을까.

또, OpenPLM처럼 3D STEP 파일을 업로드하는 것만으로 BOM이 자동으로 구성되고 각 부품들이 자동으로 배치되는 기능이 아직 없는 것 같다.
각각의 부품들을 직접 하나하나 올린 다음에 그걸 좌표 및 오리엔테이션을 입력해서 어셈블해야 하는데 이건 정말 비현실적이다.
CATIA 플러그인이 있어서 이 경우에는 자동적인 구성이 되는 것 같기는 한데, CATIA 커넥션은 유료로 별도 제공된다.
또 국내 벤더도 아직 없다.

OpenPLM이든 DocDoku이든 간에 모두 GPL V3 기반이라, 데이타 변환 같은 기능들은 FreeCAD 같은 다른 오픈소스를 갖다 넣어 쓴다.
현명하고 효율적인 선택이다.

내가 개인적으로 보기엔, 중소기업 구조설계자에게 딱 맞는 솔루션은 오히려 OpenPLM 쪽인 것 같다.
복잡성도 낮고, BOM 구성하는데 들어가는 노력과 시간을 크게 단축해 준다.
(물론 보완해 줘야 할 것들이 몇가지 있기는 하지만, 기본 개념 자체는 아주 좋다.)

OpenPLM은 철저하게 ISO10303 STEP 기초를 둔다는 개념이 확실히 처음부터 잡혀 있었기 때문이라고 생각된다.
따라서 모든 3D 데이타는 표준 STEP 파일을 통해 받아들이게 함으로써, 단순성과 범용성을 동시에 만족한다.
아울러 이 과정에서 쓸데없는 잡 정보는 다 걸러버린다.
이런 단순성은, 맨파워가 충분해서 실무자들이 일을 분업하는 것이 가능한 대기업에게는 안 맞겠지만,
소수(1명 또는 1개 팀)의 설계자가 모든 일을 감당해야 하는 중소기업에게는 꼭 필요한 특성이다.

만약 내가 PLM을 직접 개발한다면 어떻게 할까...
아마 다음 특징과 기능들을 반드시 넣을 것 같다.

(1) 제품 전체 어셈블리 모델링 파일은 3D STEP으로 업로드.
(2) 2D 도면은 PDF 및 DWG 2가지를 반드 동시에 업로드. (DWG 파일만 올릴 경우, 웹브라우저에서 직접 보기가 어렵다. 상용 솔루션을 또 사다가 갖다 붙여야 구현 가능한데 그렇게까지 할 필요가 있을까.)
(3) 부품번호=부품명칭으로 동일화하거나 부품번호 자동으로 매겨지도록 로직 구성. (이 경우 부품명칭은 반드시 유일성을 갖도록 설계자가 잘 정해야 한다. 보통 프로젝트 네임을 두문자로 넣으면 중복 우려가 크게 줄어든다.)
(4) STEP 파일을 서버에서 자동 해석해서 BOM 및 PartList 작성, 각 부품별로 STEP 파일을 분해해서 알아서 저장.
(5) 기존에 이미 저장되어 있는 것과 동일한 이름의 것으로 중복이 발견된다면, 기존의 것을 대체하여 리비전을 올릴지 또는 기존 것을 그대로 쓸지 대화창을 통해 사용자가 결정하도록 함.
(6) 사용자가 고른 2D 도면을 서버측에서 Merge해 주는 기능, 웹브라우저에서 곧바로 볼 수 있는 기능. (하나의 파일로 합쳐서 다운로드.. 실무자가 프린트하기 편하게.)
(7) 3D 모델은 WebGL로 변환해서 별도 플러그인 없이 웹브라우저상에서 직접 볼 수 있도록. (가능하면 자동 분해 또는 수동 분해 기능, 단면 짤라보기 기능 같은게 있으면 좋겠는데 없어도 무방.)
(8) 리비전 관리는 새로 파일,정보가 갱신될 때 마다 자동으로 매겨지도록 한다. 리비전 갱신될 때는 반드시 자동으로 ECR,ECO 문서가 자동으로 생성되어 PDF로 저장되도록 한다. 이렇게 하면 ISO9001 인증 준비할 때 필요한 구비서류 작업하는데 들어가는 삽질을 줄일 수 있다.
(9) BOM, PartList에 들어가는 항목(열)을 관리자가 임의로 정의할 수 있도록 한다. (예를 들어 부품 단가 항목을 새로 추가한다던가.)
(10) BOM, PartList는 Excel 포멧으로 다운로드 받을 수 있도록 한다. (한국 기업에서는 Excel과 연계 안되면 안된다!)

아마 (4)번 기능이 좀 난이도가 있을 것 같은데, 능력있는 개발자라면 능히 구현 가능하다고 본다. OpenPLM에서 구현된 바 있으니 이걸 레퍼런스로 갖다 써도 되지 않을까.

그리고 다음 기능은 뺄 것이다.

(1) 프로젝트 관리 기능 (한국 중소기업에 독불장군식 꼰대(?) 경영자들 및 변심이 잦은 고객의 존재 때문에 체계적인 프로젝트 관리가 현실적으로 어렵다는 사실을 인정하자. 정 필요하면 다른 툴을 쓰는게 낫다.)
(2) 소프트웨어 형상관리 기능 (소프트웨어 개발자의 형상관리툴은 따로 있으니.)
(3) 유저그룹 관리 기능 (불필요)
(4) PLM과의 DB 연동 (구현이 그다지 어렵지 않고, 또 필요성도 있긴 한데, 실무적으로 이걸 실제로 가동시키려면 구매팀이나 경영지원팀을 설득시켜야 하는 어려움이 존재한다. 쓸데없는 이런 노력을 할 필요가 있을까.)

아무튼 이런식으로 심플하게 구성하면 쓸만할 것 같다.

PLM에서 흔히 생각하는 3D 모델링 원시데이타를 직접 관리하겠다는 생각 자체를 버리는 것이 일의 규모를 줄여준다.
결과 데이타인 STEP 파일만 가지고 다루도록 하면 소규모 프로젝트로 충분히 쓸만하게 만들 수 있다고 생각이 된다.
그리고, 이런 컨셉으로 개발해서 오픈소스화하고, 이걸 필요한 기업에 살짝살짝 커스텀화해 주면서 저렴한 유지보수비용을 받으면서 고정수입을 얻는 비즈니스 모델도 성립하지 않을까 생각이 된다.
서버는 뭐 아마존 같은 클라우드에 올려서 해 주면, 자체 데이타센터 서버 관리도 필요 없으니까 순수한 소프트웨어 사업이 되지 않나 한다.
보통 엔터프라이즈 솔루션을 개발하는 회사나 개발자들을 보면, 그들의 고객인 '기업 경영자'를 생각하게 되는데, 영업적인 측면에서 실제 돈을 쓰겠다는 결정권자가 경영자이므로 당연하겠지만, 개발자는 그보다 실제로 그걸 사용하는 실무자(유저)를 생각해야 하지 않나 싶다.

2015년 11월 29일 일요일

경량 리눅스 신속 설치 레시피

https://github.com/dymaxionkim/UbuntuBang

요기에다가 설치 방법 설명서를 올려 두었습니다.
각종 패키지 깔고 하는건 그냥 쉘스크립트를 Git에서 받아다가 골치 아프지 않게 자동으로 되도록 해 봤어요.
대충 시간을 재보니 수동으로 하나씩 까는 것에 비해서 시간을 1/5~1/10까지 단축해 줍니다.
인터넷 속도가 그럭저럭 나온다면 아마 1~1.5시간 정도면 끝날 수 있을 것 같습니다.

구성은...

Ubuntu Server 14.04 (베이스시스템)
OpenBox (윈도우관리자)
Tint2 (태스크바)
Conky (바탕화면위젯)
PCManFM (탐색기)
다솜입력기 (다국어입력기)
Numix (테마)
Python 툴체인 (Jupyter Notebook 까지)
...

LightDM은 생략해서, 부팅후 텍스트모드에서 로그인한 후에 직접 startx 타이핑 해줘야 됩니다. (개인취향)
뭐 이런 기본적이고 무난한 거고요.
윈도우PC를 주력으로 쓰고, 버츄얼박스로 리눅스 올려서 가볍게 돌리는 경우를 상정해서 구성했습니다.

구버전에서 이런식으로 구축한 레시피가 있었는데 버전도 바뀌고 했으니 함 써서 공유해도 나쁘지 않겠다 싶어서 올려 봅니다.

일단 구성한 후에 X윈도우 진입 직후 메모리 점유율을 보니깐 110MB 정도 됩니다.

그런데 이중에 다국어 입력기가 어떤걸로 하더라도 수십MB 정도의 메모리를 먹더군요.
다솜입력기는 UIM벼루보다 조금 더 메모리를 점유하더군요. --> 오류! 사실은 반대임
대신 한영변환시 Shift+Space 뿐만 아니라 한영키로 모두 쉽게 가능하므로 좋은 듯 합니다.

아무튼 버츄얼박스에 리눅스 올려서 뭔가 하려고 할 때, 우분투 데스크탑이나 민트 같은 걸로 하기엔 너무 자원낭비다 싶을 때 쓰려고 개인적으로 만든 것입니다. 제 경우엔 주로 계산용으로...

2015년 11월 8일 일요일

Git for PDM

구글링 해 보면 이 주제와 관련하여 하나의 제안이 보인다.

http://plmdojo.com/plm/we-need-distributed-plm/

간단히 말해 CAD 데이타도 분산 버전 관리 개념을 도입하면 어떠냐는 것이다.

사실 Git을 써 본 설계자라면 자연스럽게 이런 아이디어를 떠올릴 것은 당연한 귀결이다.

과연 이 아이디어가 현실성이 있을까??

기존 상용 PDM의 특징

거의 모든 제품이 중앙집중식 파일관리 개념을 기반으로 하고 있으며, 유연성이 심각하게 떨어진다.
이유는 간단하다. CAD 소프트웨어 개발회사들이 전부 자사의 CAD 제품 안에 고객들을 가둬놓고 돈을 쪽쪽 빨아먹는다는 개념의 비즈니스 모델을 가지고 있기 때문이다.
따라서 산업 표준 호환성이나 데이타 교환의 용이성 등은 심각하게 등한시되어 왔다.

기존 상용 PDM의 문제점

사용자는 모두 온라인으로 연결해서 CAD데이타를 당겨서 써야 한다.
이런 중앙집중식 모델은 네트워크 속도가 받쳐주지 못하면 느려서 도저히 작업 진행이 안 될 지경이다. 특히 그냥 소스코드 따위의 텍스트들도 아니고, 수십~수백 메가바이트 또는 심한 경우 기가바이트 단위의 데이타를 온라인으로 당겨와서 써야 하는데 제대로 속도가 나올리 없다.
다중작업시 권한관리 문제 때문에 역시 설계자의 자유도가 떨어진다.
브랜치를 내는 것이 쉽지 않다. 이는 달리 말해, 하나의 소스 제품이 있을 경우 이에 대해 고객 요구에 따라 커스터마이제이션된 파생 모델을 쉽게 만들기 힘들다는 이야기다.
다양한 파생 모델을 만들어내야 하는 것은 주로 다품종 소량생산 제품을 만들어내야 하는 고부가가치 장비 쪽 업계에서 직면하는 문제다. 이에 대해 기존의 CAD 회사들은 제대로 된 솔루션을 전혀 제시해주지 못하고 있다.
기존 CAD 회사들의 주요 관심사는, 대규모 다국적 기업들 달리말해 큰 돈을 주는 대기업에 주로 촛점이 맞춰져 있었다.
중소기업을 위한 솔루션이라고 구색을 맞춰서 나온 것들이 있기는 하지만, 역시 실제 중소기업 현실에 맞춘 마음에 드는 솔루션을 본 적이 없다.
중소기업의 경우 1명~수명 정도의 소수의 설계 인원만으로 설계작업은 물론 도면 생성 관리 배포 파생제품 설계 생산이관 자료준비 등등 모든 단계를 모두 다 수행해야 한다. 이는 심각한 업무 로드를 강요하게 되는데, 실무자의 업무량을 진짜로 줄여주는 일에 관심을 가진 공급자는 단 한 회사도 없었다고 본다.
특히 중소기업(스타트업,벤쳐등)의 경우, 관리를 위한 관리 보다는 좀 더 유연하게 신제품을 개발하는게 중요하고 또 기존 제품들 즉 레거시 데이타의 구애를 덜 받기 때문에, 중앙집중식 데이타 관리 보다는 분산형이 훨씬 더 필요성이 높다.

diff 문제

Git은 기본적으로 텍스트 포멧을 다루는데 최적화되어 있다. 그런데, 대부분의 CAD 데이타는 바이너리 파일이다. 따라서 사용하기에 불리해진다.
diff 기능은 고도로 발달되어 있으나 역시 텍스트 이외에는 전혀 쓸모가 없다.
다만, STEP 파일을 보면 기본적으로 텍스트 포멧을 바이너리화 한 것으로 볼 수 있기 때문에 중간에 적절한 필터만 거치게 해 줄 경우 관리가 완전히 불가능한 것만은 아닐 것이다.
또한 CATIA의 Catpart, CREO의 prt 파일 등의 경우 역시 해당 포멧의 구조 중에서 헤더 정도에 해당하는 내용만 파싱해 낼 수 있다면 어느정도 관리가 가능하지 않을까 생각이 들기도 한다.
그럼에도 불구하고, 텍스트 포멧을 다룰때 보다는 훨씬 많은 용량의 저장공간과 관리를 위한 컴퓨팅 파워가 필요할 것이다.
그러나 저장공간의 가격은 매우 저렴해져 있고, 컴퓨팅 파워는 사실 PC 정도 사양만으로도 충분하지 않을까 싶다.

사용자 인터페이스 문제

소프트웨어 개발자가 아닌 기계설계자들을 위한 심플하고 깔끔한 GUI 클라이언트 소프트웨어가 제공될 필요가 있다. 또는 완전히 웹 기반으로 가도 좋지 않나 한다.
인증, 커밋, 브랜치, 머지 등등의 개념을 몰라도 자동적으로 수행되도록 세심하게 개발되어야 할 것이다.

BOM 생성 문제

가장 현실적인 방법은, CAD 종류에 구애받지 않도록 모든 정보를 포기하고 오로지 파일네임만으로 모든 것을 구성하는 것이다.
이것이 성립되려면 파일네임이 유일성을 가지도록 설계단계에서 유의해야 할 필요가 있다. 이는 설계자 교육을 통해 습관하는 것이 충분히 가능하다고 본다.

잠정 결론

아무튼, Git 기반으로 소스코드 관리가 아닌 pdf,dwg,stp 같은 바이너리 파일(도면 포함)을 분산 버전 관리할 수 있도록 솔루션을 구성하고 이를 사업화하는 방법도 꽤 재미있는 아이디어 아닐까 싶다.
한국에서 이게 나올 확률은 0%에 수렴할 것 같아 조금 슬프다.

2015년 10월 29일 목요일

기계공학용 가벼운 리눅스 배포판

CrunchBang 리눅스가 원래 Ubuntu + Openbox 조합으로 매우 가볍고 빠르면서 편리성도 갖추는데 성공한 이후, 이에 영향을 받은 여러 배포판들이 나온 것 같다.
2009년을 마지막으로 CrunchBang 프로젝트가 중단되었기 때문에 이와 같은 컨셉의 좋은 배포판에 대한 필요성이 더욱 증가하였다.

Debian + OpenBox 조합형 리눅스 배포판

BunsenLabs : https://www.bunsenlabs.org/

BunsenLabs라는 프로젝트는 CrunchBang의 직계 후계 프로젝트로 계속 이어지고 있다.
간단히 말해 그냥 CrunchBang의 업데이트가 계속된다고 봐도 될 듯 하다.
다만 CrunchBang의 마지막 버전은 Ubuntu 대신 Debian 기반으로 전환하였기 때문에, 이것 역시 Debian 기반이다. 이점은 장점이자 약점이기도 하다. 사용목적에 따라 장단점은 달라질 것이다.
일단 설치 자체는 매우 안정적이고 신뢰도가 높다. 설치후 스크립트에 의한 환경 구성 과정이 너무 세심하게 잘 되어 있어서, APM 웹서버 구축하는 것조차도 선택에 따라 설치시에 자동으로 다 이루어진다.
개인용 웹서버와 간단한 데스크탑 정도 목적이라면 Debian 기반 시스템이 좋은 선택일 것이다.
그러나 워크스테이션으로 사용하기에는 Debian 시스템의 보수성 때문에 불편한 점이 많다.
많은 공학용 어플리케이션들이 대부분 Ubuntu 배포판은 기본으로 지원하지만, Debian 배포판은 따로 제공하지 않는 경우가 많기 때문이다. 때문에 Debian에서 억지로 사용하려면 직접 어플리케이션을 빌드해서 사용해야 할 것인데, 이는 시스템 관리에 많은 시간과 노력이 낭비된다는 것을 의미한다.
또한, 하드웨어를 자동으로 잡아주는 호환성 부분이나, 기타 여러가지 편리성 측면에서도 Debian이 아무래도 Ubuntu보다 좀 떨어질 수 밖에 없다. 설치 직후 인식되지 않는 하드웨어 설정 등에 시간이 투입될 확률이 좀 있다.

Ubuntu + OpenBox 조합형 리눅스 배포판

SalentOS : http://www.salentos.it/
Madbox (32bit 버전만 제공) : http://madbox.tuxfamily.org/
GoBang : http://gobanglinux.org
Chromixium : http://chromixium.org

따라서, 편리성과 가벼움(=리소스 절약)을 동시에 달성하기 위해서는 Ubuntu + OpenBox 조합이 최선의 선택이라고 생각된다. 설치하자마자 별다른 설정 없이 그대로 사용을 시작해도 충분한 수준이라고 생각된다.
위에 조사해 본 4가지 배포판 중에서, SalentOS 및 MadBox는 사용을 안해봤다.
MadBox는 32비트 바이너리만 제공하므로 공학해석을 위해 필요한 64비트 버전이 없기 때문에 제외해야 할 것이다.
GoBang은 시험삼아 설치해 봤는데, 설치 요령은 BunsenLabs와 크게 다르지 않으며 매우 가볍기는 하나, 안정성이 좀 떨어진다는 느낌이 든다. VirtualBox 가상머신에서 게스트 확장 설치에 실패했다. 다운되는건 아닌데 내부적으로 충돌이 좀 있어 보인다.
Chromixium은 OpenBox 기반이기는 하나, Tint2 대신 Plank Dock을 기본적으로 사용하기 때문에 훨씬 더 예쁘다. 계속 활발하게 업데이트가 이루어지고 있어서 이제는 매우 안정성이 높아졌다.
편리성을 포기하지 않으면서 동시에 메모리 절약 등 가벼움을 원한다면 현재로서는 가장 좋은 선택이라고 생각된다.
물론 가볍다고는 하지만 GoBang 수준으로 터무니없이 가볍지는 않다. GoBang이나 BunsenLabs의 경우에는 환경설정 대략 해 주고 부팅하면 메모리 사용량이 300~400MB 수준이다. 마우스 클릭시 반응속도는 뭐 말할 필요도 없다. Chromixium은 필요한 환경설정을 대충 해 주고 부팅하면 메모리 사용량이 600~700MB 수준이다. 구글 크롬북을 흉내낸 데스크탑 디자인 때문에 나름대로 산뜻한 느낌을 준다.
내가 이런 가벼운 배포판를 찾는 이유는, 가용한 PC의 메모리가 4~8GB에 불과한 경우가 많기 때문이다. 16GB~32GB 정도의 메모리를 가지고 있다면 고민할 필요가 크게 없다고 생각된다. 그때는 그냥 일반적인 Ubuntu Unity, Mint 같은 것을 사용하는 것이 더 편리하기 때문에 시간낭비를 크게 막아줄 것이다.
유한요소 해석을 할때, 대략 20만개 수준의 엘리먼트를 해석하면 4GB 메모리로도 충분히 커버 가능하다. 그런데 100만개 수준의 엘리먼트를 해석할 경우에는 거의 100% 실패한다. 메모리가 기하급수적으로 소모되기 때문에 메모리 용량은 나름대로 중요한 문제가 된다.
OS에서 기본적으로 점유하는 메모리를 아낄 수 있다면 좀 더 나을 것이고, 또 OS의 환경구성 복잡도가 낮아 단순하다면 더욱 해석에 유리할 것이라고 나름 생각한다.
또한, 리눅스 구성 자체에 재미를 느끼는 오타쿠(?)가 아닌 평범한 기계공학 엔지니어의 경우에는... 리눅스 사용 자체에 거부감을 느끼는 경우가 많다. 컴퓨팅 자체 보다는 설계 해석 행위 자체가 주관심사이기 때문이다. 컴퓨터는 그냥 도구라는 생각이 강하기 때문에, OS 구성하고 셋팅하는데 시간낭비가 없는 것이 좋겠다.
기계공학 엔지니어가 사용할 어플리케이션은 기껏해야 다음 정도다.

유한요소해석 솔버
C,C++,Python 등의 간단한 개발환경
3D CAD 관련 어플리케이션들
간단한 웹서버 운용
SAMBA, SSH, FTP 정도의 유틸리티들
웹브라우저

무거운 배포판은 필요가 없다.

2015년 10월 13일 화요일

Wiki and Jupyter

위키

여러가지 위키를 상당기간 검토하거나 사용해 봤다.
미디어위키. 일단 가장 표준적인 시스템이라는 점에서 보증할 수 있고, 기능이 풍부하며, 확장성 역시 좋다. 그러나 미디어위키 문법은 아주 지저분하고, APM 시스템 기반이라 포터블 하지는 못하다.
깃허브 골룸. DB 의존적이지 않은 대신 Git을 통해 버전관리가 이루어진다. 어차피 DB가 필요한 만큼의 대규모 위키를 운영할 것도 아니므로 이것은 전혀 문제되지 않는다. 또 깃허브 향 마크다운 문법 역시 매력적이다. 설치 방법도 크게 까다롭지는 않다. 그럼에도 불구하고 뭔가 부족하다는 느낌이 든다. 하지만 기본 개념 자체는 아주 좋다.
징고(Jingo). 골룸 비스무레한 것을 node.js와 자바스크립트로 만들어 놓은 것이다. 역시 상당히 좋지만 아직 완성도가 너무 낮다. 겨우 구색만 갖춘 느낌. 그러나 역시 node.js 기반의 소프트웨어는 항상 나를 기쁘게 한다.
티들리위키. 단순무식한게 아주 좋고, 달랑 하나의 파일만으로 포터블성이 극대화된게 아주 천재적이다. 다만 기본 UI가 위키라기 보다는 블로그에 가깝다. 아쉬운 점은, 티들리위키 문법을 사용하고 싶지는 않기 때문에 마크다운 플러그인을 넣어 봤는데 지나치게 허접하다는 점이다.
기타 서비스형 위키로, Torchpad를 사용하고 있는데... 골룸처럼 깃허브향 마크다운 문법 기반이라 너무 좋고, 필요한 확장이 모두 기본적으로 셋팅되어 있을 뿐만 아니라, 그림 삽입 같은 것은 그냥 마우스 드래그만 해 주면 자동적으로 업로드 및 태깅이 되기 때문에 너무 편하다. 단점은 한글 입력시 끝글자가 사라져 버리는 버그가 있고, 깃허브 연동 기능이 아직 제공되지 않는다. 그리고 커뮤니티가 거의 죽어있는 것을 봐서는 곧 망할 것 같은 느낌이 들어 불안하다. 서비스형 위키는 아무래도 내가 통제할 수 없다는 점 때문에 심리적인 불안감을 떨치기 어렵다.

Jupyter

그런데, iPython notebook 즉 Jupyter를 보면, 기본적으로 훌륭하게 마크다운 문법이 지원되는 점을 볼 수 있다.
게다가 한큐에 서버 셋팅까지 되고...
각종 언어 커널만 심어주면 인라인으로 코딩 및 결과까지 보여준다.
그리고 이 모든 걸 전부 다 .ipynb 파일 하나에 싹 다 저장할 수 있다.
게다가 온라인, 오프라인 어느쪽으로든 이건 .html로 렌더링을 쉽게 해 줄 수 있다.
심지어 깃허브에서는 직접 렌더링해서 볼 수 있다.
아무튼 킹왕짱이다.

아이디어

아이디어는 간단하다.
Jupyter를 뜯어고쳐서(?) 골룸 위키 처럼 만들어보면 어떨까?
즉 위키 문서 파일 역할을 .ipynb 파일이 하도록 시스템을 구성해 주고, Jupyter 프론트엔드 쪽에 문서 검색기능 같은 추가 요소를 더 주는 것이다.
그리고 화면 좌측에 트리 같은걸 자동 생성해서 브라우징 할 수 있도록 해 주면 더 좋겠다.
그리고 열람 모드에서는 Jekill 같은 느낌으로 그냥 열람만 할 수 있도록 하고, 편집 모드에서는 Jupyter 네이티브로 편집 가능하도록 해 준다.
그러면 코딩과 문서의 환상적인 조합이 이루어질 뿐만 아니라, 퍼블리싱까지 되는 셈이다.

2015년 10월 1일 목요일

JINGO !!!

개요

깃허브 홈페이지 : https://github.com/claudioc/jingo
한 줄 소개 : node.js로 작성한 Git 기반 위키엔진. 봐줄만한 디자인, 검색기능, 미려한 폰트.

Introduction

Git과 Markdown을 중심으로 한 문서작성체계를 가지고 싶은 사람을 위해 만들어졌음.
복잡하고 과잉기능의 도구에 질려버린 사람에게 좋음.
Github 자체 위키 엔진인 Gollum의 영향을 강하게 받았음.
다만, Gollum 보다는 좀 더 독립실행에 유리하도록 완결성을 주었음.
"Github 없이도 쓸 수 있는 좀 더 강력한 Github 위키"
Jingo = Jingo is not Gollum
데모 홈페이지 : http://jingo.cica.li:6067/wiki/home

Features

데이타베이스 사용하지 않음 : 대신 Git 레포지토리 기능을 활용함
사용자 관리 불필요 : 구글계정,깃허브 계정으로 간단히 로그인하는 기능 지원
완벽한 마크다운 문법 지원 : 깃허브향 마크다운도 지원
Codemirror 또는 Markitup 사용 : 훌륭한 ajax 보여주기 (설정 파일 참조)
전화면 에디터 모드 지원 : 집중력 강화
Gollum 위키에서 만든 문서와 호환
모든 문서에 버전 관리 지원
상이한 버전의 문서간에 비교 기능 지원
모든 문서에 페이지 매기기 기능 지원 : 버전 간에 변화된 부분을 빨리 찾을 수 있음
내용 및 제목 검색 지원
Sidebar, Footer 레이아웃 설정 가능
Gravatar(개인 아바타) 지원
IFRAME 삽입 가능 (예 : 구글 드라이브 문서를 embed할 수 있음)
커스텀 CSS 및 Javascript 적용 가능
문서를 읽고 쓸 때 권한을 줄 수 있는 화이트리스트 지원
빈 페이지 검출 기능 (붉은 색으로 나타남)
Remote로 자동 Push 기능
모바일 대응 (Bootstrap 3.X 기반)
간편한 설정

코드 하일라이트 기능으로, node-syntaxhighlighter를 사용함. 지원하는 언어는 이 페이지 참조.
Code

Installation

node.js 및 npm 설치

우분투 리눅스 14.04 기준. Git이 설치되어 있을 것.

sudo apt-get install nodejs nodejs-legacy npm

Jingo 설치

sudo npm install jingo

Git 설정하기

Git 사용법 참고 : https://backlogtool.com/git-guide/kr/intro/intro1_1.html

mkdir /home/홈폴더/jingo
cd /home/홈폴더/jingo
git init
git config --global user.name "아이디"
git config --global user.email "이메일"

Jingo 기본형 설정파일 만들기

jingo -s > config.yaml

Jingo 로그인 비밀번호 해쉬코드 만들기

jingo -# 비밀번호

위의 명령을 치면 해쉬코드가 나온다. 그걸 긁어서 복사해 둔다.

config.yaml 편집하기

편집기로 config.yaml을 열어서 다음의 내용을 손 봐준다.

---
# Configuration sample file for Jingo (YAML)
application:
  title: Jingo
  repository: '/home/홈폴더/jingo'      <--- Git 저장소로 설정한 디렉토리 절대경로
  docSubdir: ''
  remote: ''
  pushInterval: 30
  secret: change me
  git: git
  skipGitCheck: false
  loggingMode: 1
  pedanticMarkdown: true
  gfmBreaks: true
  staticWhitelist: "/\\.png$/i, /\\.jpg$/i, /\\.gif$/i"
authentication:
  google:
    enabled: false                 <--- Google 로그인은 일단 비활성화 해 두자.
    clientId: replace me with the real value
    clientSecret: replace me with the real value
  github:
    enabled: false                 <--- Github 로그인도 일단 비활성화 해 두자.
    clientId: replace me with the real value
    clientSecret: replace me with the real value
  local:
    enabled: true                 <--- 로컬 로그인만 활성화 해 두자.
    accounts:
      - username: '아이디'                 <--- 아이디
        passwordHash: '해쉬코드'         <--- 아까 만들어서 복사해 둔 해쉬코드를 넣어준다.
        email: '이메일'    <--- 이메일
features:
  markitup: false
  codemirror: true
server:
  hostname: localhost
  port: 6067
  localOnly: false
  baseUrl: ''
authorization:
  anonRead: true
  validMatches: .+
pages:
  index: Home
  title:
    fromFilename: true
    fromContent: false
    asciiOnly: false
    lowercase: false
  itemsPerPage: 10
customizations:
  sidebar: _sidebar.md
  footer: _footer.md
  style: _style.css
  script: _script.js

Jingo 첫 실행

jingo -c /home/홈폴더/jingo/config.yaml

잘 되나? 잘 되면 설정해 둔 아이디와 패스워드로 로그인 한 후, 첫번째 home 문서부터 작성해 보자.

남은 일들

Github와 연동시키기 : 나중에 천천히 하자.
Google 및 Github 계정으로 간편 로그인 기능 설정하기 : 나중에 천천히 하자.
다른 Javascript 스크립트 먹이기 : 나중에 천천히 연구해 보자.
서버에 올려서 서비스하기 : 나중에 천천히 연구해 보자.

2015년 9월 12일 토요일

새로운 직장에서의 난해한 과제들

이직하고 나서 새로운 직장에서 적응하려고 안간힘을 쓰는 중이다.

이직하면서 몇가지 패널티를 안고 왔다.

(1) 원래 모시던 상사의 추천으로 입사.
(2) 주력 CAD 소프트웨어가 변경됨.
(3) 제품의 도메인이 변경됨.

때문에, 새로운 직장에서의 적응이 좀 더 어려워진 상황이다.

원래 4곳 정도의 사업체에서 러브콜을 주셨는데, 그중에 선택한 것이 지금의 직장이었다.
현재의 연봉보다 2배 가량 더 높은 금액을 제시해 주신 곳도 있었는데, 엔지니어의 정체성을 유지하기 힘들 것으로 예상되고 또 외국을 너무 자주 나가야 하는 점 때문에 고사했다.

어쨌든 형식이 추천으로 입사한 것이다 보니 일부 사람들은 뒷담화로 '낙하산이다'라고 오해하면서 '실력도 없는게 나댄다'라는 식으로 나쁘게 보는 사람이 있을지도 모른다.

또 주력 CREO에서 CATIA로 소프트웨어가 바뀌게 되었는데, 생각보다 CATIA 학습기간이 길어지고 있다. 당면한 긴급업무에 의해 짬을 내기가 쉽지 않아진 것도 있고, 또 십수년 전에 내가 CATIA를 쓸 때와는 비교할 수 없을 정도로 이 소프트웨어의 복잡도가 높아져 있다는 사실을 발견했기 때문이다.
다행스러운 점은, CREO에서 적용했던 설계 기법들을 거의 그대로 원용하는 것이 가능하다는 점이다. 약 4 주간에 걸쳐 틈틈이 학습한 결과, 표준에 맞추어 원하는대로 Setting를 완료하는데 성공했고, Top-down 설계를 적용할 수 있는 레시피를 얻었다. 몇가지 중요한 단축키의 사용에도 조금씩 익숙해지고 있다.
다만, 실무 현업에서 보니까 CATIA 유저들의 설계기법이 생각보다 굉장히 원시적이라는데서 매우 놀랐다. 이렇게 좋은 툴을 가지고 이런 엉망진창의 데이타를 만들어내고 있었다니... 헐.
기존 제품들의 설계 데이타들을 몇 가지 조금씩 뜯어보고 있는데, 소프트웨어 분야에 빗대어 표현하자면 일종의 '스파게티 소스코드'를 들여다보는 느낌이 들었다.
레퍼런스 로직도 엉망진창이고 원칙도 없고 일관성도 없고... 그냥 되는대로 모델링을 해 놓았으며, 도면 표준에 맞추었다는 셋팅도 보니까 제대로 안 맞는 것들이 많았다. 폰트도 중구난방...
선임자들의 변으로는, 너무 짧게 주어진 설계시간에 맞추다 보니 그렇게 흘러왔다는 것이다. 전임 경영자의 밀어부치기식 경영 습관 때문에 그렇다는 것이다.
예전에 이런 식으로 전투기를 설계했었나 하는 생각을 하니 정신이 아득해진다.

게다가 전임자들 및 현직 재직자들은 자신들이 오랫동안 경험해온 경험이 최고수준의 것이라는 생각을 하고 있는 것 같았다. 굴러온 돌은 믿을 수 없다는 티를 너무 노골적으로 내는 장면이 많았다. 조금 노골적으로 표현하자면 약간의 텃세 같은 것?
나를 기술적으로 전혀 신뢰하지 않는 시선이 느껴지는데 매우 자존심이 상하기는 하지만, '엔지니어의 방식'을 통해 그런 점은 시간을 두고 쉽게 극복 가능하다고 생각한다.
기술적으로 오만한 엔지니어는 더이상 엔지니어가 아니라는 사실을 항상 명심하자.

그건 그렇고 기존 제품의 설계 품질을 보니, 로직 측면에서의 저수준도 문제지만, 기구설계적인 기본 원칙이나 기초를 무시한 소위 '날림 설계'가 너무 많아서 어디서부터 손을 대야 될지 멘붕이 올 정도다.
얼핏 보면 무슨 대학생 졸업작품인줄 알 정도였다.
(물론 그렇게 된 이유는 개발자의 자질이 낮아서 그런 것은 아니라고 생각한다. 이런 경우는 개발자의 운신의 폭을 제한하는 제반상황, 영업조건 등의 영향이 크다.)

Top-down 계획설계 기법의 적용을 CATIA 유저들이 기피하는 경향이 굉장히 심하다. 매우 놀랍다. 바빠서 그렇다고 하는데, 아무리 바빠로 잘 적응되면 설계 생산성에 전혀 문제 없을 뿐만 아니라, 팔로우업 과정에서 점차 설계수정 소요시간이 단축되는 효과를 볼 수 있는데 이 친구들은 아직 그런 경험을 해 본 적이 없어 보였다.

더 심각한 것은, 기존 재직 설계인원들의 타성이 심해서 어떠한 변화도 모두 거부하는 태도를 보이고 있는 것 처럼 보이는 점.... 또 부하직원으로 함께 들어온 열 몇 살 나이 차이가 나는 친구가 나를 제대로 된 선배나 상사로 취급하지 않는다는 점(자존감이 있어 보여 좋아 보이기는 하는데, 한번씩 나를 죽일 듯이 노려볼 때는 등골이 오싹함) 등이 우려된다.
뭐하나 잘못하기라도 하면 당장 왕따라도 당할 기세다.

아무튼 이런 어려운 점들이 있기는 하지만, 역시 나로서도 부족한 점을 많이 느끼게 되었다.
특히 부족한 도메인 지식을 빠른 속도로 따라잡는 과제는 많은 노력을 필요로 할 것 같다.

또 나의 경상도 억양 때문에 간혹 받는 오해들(싸우는 말투 같다는 등)을 어떻게 이해받을 수 있을까 하는 것도 어려운 문제인 것 같다. 냉정하게 이야기해서 내 고향이 대구라는 점은 큰 패널티다.

아무튼,
이직을 하면서 마음속으로 버린 것이 있다.

리더쉽에 대한 욕구를 버리기로 했다.
전 직장에서는 내가 이끌던 팀의 운명은 내 손에 달려 있었고, 그 때문에 팀원들을 보호하고 지켜주면서 동시에 어린 친구들의 실력을 향상시키기 위해 거의 주입식 교육을 실시했었다.
덕분에 그 친구들은 나름대로 실력의 향상을 맛볼 수 있었고 들어간 노력 대비 30% 정도 따라온다는 느낌을 받아 목표 수준을 충족했었다고 자평했다.
또 최소한의 자원으로 회사의 설계데이타 관리 시스템을 개선시키고 구축했다.

그러나 새로운 직장에서는 내가 리더쉽을 가질 수 있는 공간이 없다.
보통 엔지니어가 도메인 지식에 지나치게 의존하는 것은, 공학 실력의 한계에 도달할 때 정치적으로(말빨로) 극복하기 위한 일종의 꼼수이다.
그런데 나는 정치에 약한 타입이니... 상극이다.
그런 방식으로는 좋은 결과를 얻을 수 없다.
정치를 하지 말자고 매일매일 다짐한다.

일단은 당면한 일에 집중하고, 중장기적으로 목표한 시스템 컨스트럭션 작업은 속도 조절을 해서 늦춰 보기로 한다.

또 부하직원과의 협업량은 일단은 조금 줄이는게 현명하지 않나 하는 생각이 들었다.
아무리 좋은 기술과 프로세스라도 받아들일 생각이 전혀 없는 상태에서는 강요할 수 없으니....

2015년 7월 7일 화요일

Naver Library

지난주에 집사람이랑 함께 성남 정자동 네이버 본사 건물에 구경갔다.

네이버 도서관이 있는데 무료개방하고 있다고 하길래 놀러갈 겸 해서였다.

로비에 커다란 네이버 캐릭터 인형이 덜렁 매달려 있던데 꽤 귀여웠다.

잡지 등이 놓여있는 완전 개방 공간...

신분증 내고 들어가는 아카이브 쪽에는 꽤 흥미로운 책들이 많았다.

특히 미술, 디자인 쪽 책들이 좋은게 많았는데 오래 머물지 못해 아쉬웠다.

어떤 직원이 샀는지 모르겠는데 암튼 네이버 안에도 이런 거에 관심있는 직원이 있었구나 싶네...

내부의 위 층에는 백과사전류가 있었는데, 위에서 아래쪽 서가를 내려다보니 인테리어를 너무 잘 해 놨다. 한 2시간 있어보니 에어컨을 너무 빵빵하게 틀어놔서 좀 추울 정도였다.

건물 구조가 상당히 마음에 들던데, 에너지 사용 측면에서는 아직 충분히 건축 쪽에서 연구가 되어있지 못하지 않나 하는 생각도 잠시 해 봤다.

여기 보니깐 초등생 정도의 자녀를 데리고 온 아빠들이 있던데 참 보기가 좋았다.

네이버라는 회사가 한국에서 그나마 골목대장 노릇을 하다 보니

욕도 많이 먹고 또 심지어 나도 네이버 소프트웨어들을 별로 안 좋아하는데...

이런 도서관 개방 같은 것은 상당히 개념있는 기여활동이라고 생각이 된다.

이제 소프트웨어만 개념있게 잘 만들면 될텐데...

2015년 7월 5일 일요일

Jongrae - 공학자를 위한 Python 사용법 (링크 스크랩)

구글링을 하다가 우연히 검색된 좋은 자료라서 스크랩 해 둡니다.
텀블러에 올라간 자료라서 열람하기에 조금 불편하긴 하지만...

Python의 사용방법들 중에서 공학용으로 사용하기에 좋은 소위 Scientific Python 툴체인을 사용하는 과정을 첫걸음부터 아주 친절하게 설명해 주신 내용입니다.
한국어로 된 자료들 중에서 이정도로 입문자를 위해 친절하게 된 자료는 아직 거의 별로 없는 것 같아서 소중한 자료인 듯 합니다.

글을 쓰신 김종래 박사가 어떤 분인지 잘 몰랐는데, 링크를 따라서 보니깐 영국 글래스고 대학교 교수를 역임하고 현재는 영국 리즈(Leeds) 대학교의 Robust Lab 교수로 계신 분인 듯 합니다. ( https://sites.google.com/site/robustlabjongrae/ )

Python 같은 것들은 범용 언어이기 때문에, 찾을 수 있는 대부분의 초보자용 강좌 도큐먼트들은 대부분 일반적인 어플리케이션 개발자 또는 웹 개발자를 위한 강좌 위주라서, 기계공학도에게는 잘 맞지 않아서 아쉬웠는데, 기계공학-제어공학 하는 교수님이 이런 자료를 작성해 주니까 역시 도움이 되는 것 같습니다.

Jongrae - 공학자를 위한 Python 사용법

2015년 6월 24일 수요일

개인 위키를 어디다 만들까?

개인 위키를 어디다 만들까?

블로그에다가 각종 테스트한 것들을 계속 올려보니 문서들의 조직화가 안되기 때문에 한계성을 느끼게 되었다. 또 html을 직접 건드리면서 편집하는것도 이제는 염증이 생긴다.
그래서 위키 쪽으로 생각을 해 보았는데, 집에다가 서버 돌릴 생각하니 너무 끔찍해서 그냥 공짜로 위키를 쓸 수 있는 방안을 모색해 보기로 했다.

* 첫번째 시도

일단 맨 처음에는 호스팅 업체 쪽에서 제공하는 무료 플랫폼을 알아봤는데, 고르고 골라 본 게 호스팅어(Hostinger) 였다.
무료계정 신청하고 들어가 보니, 온갖 패키지들을 원클릭으로 설치해서 사용할 수 있도록 엄청나게 잘 되어 있었다. 미디어위키 역시 그냥 누르고 설정만 몇 개 해 주니까 그냥 쨔잔 하고 되는게 아닌가!!!
다만 서버가 영국에 있다고 나오는지라 반응 속도는 조금 느린 편이지만 못 쓸 수준은 아니고 상당히 좋았다. 제공 용량도 충분하고...
하지만 문제점은, 처음 셋팅하고 이것저것 건드려보다 보니 갑자기 접속이 끊어져 버리는 현상이 나타났다. CPU 점유율이 올라가면 서버쪽에서 트리거링 되어서 자동으로 접속 끊어버린다고 하던데 이것도 그런 경우인가 싶기도 한데, 이런 현상이 자주 나타난다면 신뢰성 측면에서 도저히 안심이 되질 않는다. 데이타가 통째로 날아가 버리는 사태가 발생할 확률이 아무래도 무시 못할 듯 하다.
또 호스팅 형식으로 한다면 패키지 버전 관리다 뭐다 해서 골치아픈 일이 많을 것 같다.
결국 보류해 두기로 했다.

* 두번째 시도

꼭 개인 계정으로 꽁꽁 숨겨둘 필요는 없으므로, 다른 관점에서 접근해 보기로 했다.
바로 위키독스(WikiDocs)로 온라인 책을 써 보는 거다.
위키독스 만든 분도 꽤 괜챦은 개념인 같아 보여서 믿음도 가고, 또 내용이 풍부해지면 공개해서 기여도 할 수 있을 것 같아서 좋아 보인다.
게다가 마크다운 태그 기반으로 먹일 수 있어서 더 좋다. 세심하게 개발되어 있어서, 그림을 업로드해서 붙여주는게 거의 원클릭으로 된다.
단점은 위키독스 같은 서비스는 거의 전부 소프트웨어 개발자들 위주의 것들이다보니 기계공학 쪽 주제로 하면 왠지 혼자만 튈 것 같아 좀 쪽팔린다.
또 너무 퍼블릭한 서비스라서 완성도가 낮은 결과물일 경우에도 쪽팔림이 있을까 두렵네... 책을 쓴다는 느낌은 아무래도 부담스럽다.
또하나 치명적인 단점은, 데이타를 내 쪽으로 통째로 백업받는 기능이 안 보인다. 그냥 전부 온라인에서 작업하는 것만 가능한 것 같다. 이렇게 하는게 간단하긴 한데 그래도 뭔가 안되는게 있으니 찜찜한 느낌이다.

* 세번째 시도

깃허브(GitHub)에서도 위키가 있으니 그걸 써 볼까 싶은 생각이 들었다. 실제로 그런식으로 쓰는 사람도 있다고 하니...
이걸 쓰면 부수적인 효과로 Git 공부도 되고 좋겠다 싶다.
그림 올리는 건 Issues 기능에다가 그림 올린 다음에 그걸 퍼다 쓰면 되는 꼼수가 있는 것도 알았다. 또 자체 홈페이지 운영도 가능하므로 웹을 잘 다룰 수 있게 된다면 그것도 좋을 듯 하다. 일단 최고로 간단하게 설정해서 만들어 봤는데, 나름대로 봐줄만 하긴 하다. 문제는, 나는 웹개발에 별 관심이 없다는 거다. 앵귤라, 부트스트랩, 지킬 등 온갖 자바스크립트 프레임웍들을 이용해서 뭔가를 만들거나 다뤄야 하는데 영 자신도 없고 의지도 없다. 이거 공부해서 팔 거면 진작에 웹 개발자 했겠지... ㅋㅋ
그냥 있는거 갖다 써서 운영하는 것도 가능하므로 욕심만 안 내면 되긴 되겠다.
확실한 건 깃허브가 요즘 대세이고, 그게 아주 오래 갈 것 같다.
대세에 편승한다는 점에서는 장점이 있을지도 모른다.

이상 세가지 경우에 대해서 시험삼아 기본적인 셋팅은 전부 다 해 봤다.
전부 다 운영하는건 미친 짓이므로 하나를 골라야 될 텐데, 어느쪽이 좋을지 아직 확실히 잘 모르겠지만 현재까지는 깃허브 쪽으로 마음이 기우는 듯 하다.

마크업 태그는 사용해 본지 얼마되진 않았는데, 사내 자료 축적용으로 운영하는 미디어위키에다가 자료들을 작성해 보니 꽤 좋다는 느낌이 들었다.
위키독스 및 깃허브 쪽은 미디어위키의 것보다 좀 더 발전된 마크다운을 사용하도록 되어 있는데, 써보니까 좀 더 간결해서 더 좋다는 느낌이 들었다.

아무튼 점수를 내 보니까, 첫번째 호스팅 서비스 쓰는것은, 확장성이나 자유도 면에서는 우월하지만, 유지관리에 들어가는 리소스가 너무 많을 것이므로 아무래도 피하는게 맞는 것 같다.
위키독스는 내용작성 그 자체에만 집중하는데는 좋겠지만 부수적 효과는 기대하기 어렵다.
깃허브는 이왕 하는 김에 Git도 좀 다뤄보고 하면 일석이조가 될 것 같다. 신뢰성도 가장 월등하고 용량제한도 없고... 또 clone 해서 오프라인으로 작업해도 무방하고...
어차피 독자를 염두에 두고 기록을 남기는 것도 아니므로, 깃허브로 가는게 맞지 않나 하는 생각이 든다.

2015년 6월 17일 수요일

Mechanical Contact Analysis with Elmer

Non-linear Contact 해석은 원래 Elmer에서 수행하기에 그다지 적합하지 않았다.

이유는 Elmer에서 지원되는 관련 기능은 가상의 접촉선을 함수나 직선으로 표현한 후,
그 이상 변형되지 않도록 Limit을 걸어서 변형량을 제한하는 기능 밖에 없었기 때문이다.

MultiBody 상황에서, 상호 접촉되는 영역을 찾아낸 후, 간섭 깊이를 노드별로 계산해서 그에 따라 Load를 걸어주는 전형적인 Hertz 접촉 해석 알고리즘이 없었던 것이다.

때문에 변형량을 인위적으로 제한하는 변칙적인 방법을 쓸 수 밖에 없었는데...

그런데 최근에 Elmer 개발팀이 왠일로 접촉 해석에 대해서 관심이 생겼는지, 그와 관련된 기능을 추가한 것 같다.
광고도 없고 공지도 없고 설명서 따위도 없이 그냥 Github에 슬그머니 업데이트 해 둔 것을 보았다.

https://github.com/ElmerCSC/elmerfem/tree/contact/fem/tests/ContactPatch3D

내역을 보니 테스트 완료 업데이트 된 것이 딱 일주일 되었다.
따끈따끈하다.

아무튼 닥치고 내려받아서 테스트 해 봤는데 잘된다.

case.sif 파일의 관련 문구들의 의미는 설명서가 전혀 없기 때문에 전부 파악하기는 아직 무리다.

다만 원래 있었던 "Mortar BC" 및 새로 추가된 것으로 보이는 "Contact BCs" 경계조건을 혼합해서 사용하고 있는 듯 하다.

여기서 "Mortar BC" 라는 것은, 자기장 해석을 위해 Elmer팀이 만들어 넣었던 기능인데 2개의 MultiBody가 접촉되어 있을 경우, 한쪽에서 발생하는 물리량을 접촉된 다른 쪽으로 전달할 수 있게 해 주도록 하는 것으로 파악된다. (나도 아직은 충분히 이론 학습과 연습을 한 상태는 아니라서 정확한 설명인지는 모르겠다.)

아무튼 그래서 Mortar BC를 이용해서 두 개의 바디가 서로 상대운동하면서 위치가 변하는 상황에서 전자기 플럭스라던가, 온도 같은 것들을 각 스텝별로 전달하는 것이 가능한 것 같다.
이를 응용해서 이번에는 Load를 전달하는 것으로 생각된다.

Contact BC의 경우는, 구체적으로 설명된 자료가 없어서 추측만 해 볼 수 밖에 없는데....
변위에 의해 발생하는 침투량을 계산해서 발생하는 Load를 계산해 내는 전형적인 접촉 해석용 기능 아닐까 싶다. 물론 접촉되는 영역을 디텍트 해 내는 기능도 있을 것으로 추측되는데 아직 확인이 안된다.

또 경계조건의 특성은 "Initialize Dirichlet Conditions = False" 으로 선언된 것으로 보아, 기본 셋팅된 경계조건과는 좀 다른 것 같다.
( 참고 : https://en.wikipedia.org/wiki/Dirichlet_boundary_condition )

아무튼 정확한 Notation이나 구조 파악은 현재로서는 어려우나, 일단 제시된 예제를 사용해서 해 보았고, 그것을 조금 변형해서 Scanning도 해 보았다.

나중에 시간이 나면 일반적으로 사용할 수 있는 수준인지 검증해 볼 수 있을 듯 하다.
임의로 변형한 솔버 인풋 파일은 아래와 같다.
모델 데이타 자체는 원래의 것을 그대로 사용하였다.
(아쉬운 점은, 모델링된 데이타가 1/4만 그린 후 대칭성을 이용해서 조합하는 방식으로 구성되어 있는지라, 접촉 해석 관련 부분만 따로 떼어서 보기가 조금 헷갈린다.)




Header
  CHECK KEYWORDS Warn
  Mesh DB "." "cubes"
  Include Path ""
  Results Directory ""
End

$fileid="c"

Simulation
  Max Output Level = 20
  Coordinate System = Cartesian 3D
  Coordinate Mapping(3) = 1 2 3
  !Simulation Type = Steady State
  Simulation Type = Scanning
  Timestep intervals = 200
  Timestep sizes = 1

  Steady State Min Iterations = 1
  Steady State Max Iterations = 1

  Post File = case_$fileid$.vtu
  Save Geometry Ids = Logical True

  Mesh Levels = 2

! The ElasticSolver does not really like the Dirichlet conditions at the start 
! of the nonlinear iteration. 
  Initialize Dirichlet Conditions = False
End

!Constants
!  Gravity(4) = 0 -1 0 9.82
!End

Equation 1
  Name = "Deformation"
  Active Solvers(1) = 1
  Plane Strain = Logical True
End

Body 1
  Name = "Lower block"
  Target Bodies(1) = 55
  Equation = 1
  Material = 1
End

Body 2
  Name = "Upper block"
  Target Bodies(1) = 56
  Equation = 1
  Material = 1
End

Material 1
  Name = "Ideal"
  Youngs modulus = 90.0
  Density = 10.0
  Poisson ratio = 0.25
End

Solver 1
  Equation = "Nonlinear elasticity"
  Procedure = "ElasticSolve" "ElasticSolver"
  Variable = -dofs 3 Displacement

  Nonlinear System Convergence Tolerance = 1.0e-5
  Nonlinear System Max Iterations = 10
  Nonlinear System Relaxation Factor = 1.0

  Linear System Solver = "Iterative"
  Linear System Iterative Method = "BiCGStab"
  Linear System Abort Not Converged = True
  Linear System Preconditioning = "ILU2"
  Linear System Residual Output = 100
  Linear System Max Iterations = 5000
  BiCGStabl Polynomial Degree = 4
  
  Linear System Convergence Tolerance = 1.0e-10

  Apply Contact BCs = Logical True
! Save Contact = Logical True

! Restore the linear solution
! Elasticity Solver Linear = Logical True

  Calculate Stresses = Logical True
! Optimize Bandwidth = False

  Displace Mesh = Logical True
! Calculate Boundary Weights = Logical True

! Do not include constraints when analyzing the convergence and norm of a solution
  Nonlinear System Convergence Without Constraints = Logical True
End

Solver 2
  Exec Solver = never
  Equation = "SaveLine"
  Procedure = "SaveData" "SaveLine"
  Filename = f_$fileid$.dat
End

Boundary Condition 1
  Name = "Support"
  Target Boundaries(1) = 57
  Displacement 3 = Real 0.0
End

Boundary Condition 2
  Name = "Lower surface of upper block"
  Target Boundaries(1) = 58

  Mortar BC = Integer 3
  Mortar BC Nonlinear = Logical True
  Contact Depth Offset Initial = Real 1.0e-3
  !Contact Active Set Minimum = Integer 1
  !Contact No-Slip = Logical True

! Create a strong projector for the line setting y-coordinate to zero
  Flat Projector = Logical True

! a) Use weak projector or not
  Galerkin Projector = Logical False

! b) Use more tailored projector able to do accurate integration
  Level Projector = Logical True
  Level Projector Generic = True
End

Boundary Condition 3
  Name = "Upper surface of lower block"
  Target Boundaries(1) = 59
End

Boundary Condition 4
  Name = "Pressure load the upper surface of upper block"
  Target Boundaries(1) = 60
  !Normal Surface Traction = -1.0
  Normal Surface Traction = Variable Time
    Real MATC "-1*sin(2*pi*tx/200)-1"
End

Boundary Condition 5
  Name = "Symmetry y-z"
  Target Boundaries(1) = 61
  Displacement 1 = 0.0
End

Boundary Condition 6
  Name = "Symmetry x-z"
  Target Boundaries(1) = 62
  Displacement 2 = 0.0
End


Solver 1 :: Reference Norm = 0.66961642E-02
Solver 1 :: Reference Norm Tolerance = 1.0e-6

아무튼 이 기능이 잘 발전되고, 나중에 GUI에까지 반영이 된다면 Elmer가 Mechanical CAE 하는데 훨씬 더 활용성이 높아질 것 같다.
OpenSource CAE 툴 중에서 가장 접근하기 쉬운게 바로 Elmer 이기 때문에, 매우 손쉽게 고수준 해석에 도전할 수 있는 환경이 되는 것이다.