人にモノを教えるということ
ご無沙汰しております。
ishizawaです。
最近急に寒くなってきましたね。
先週体調を崩して熱を出したのは私です。
皆さんも体調には気を付けましょう。
今日は私が最近よく行う新人の教育について整理も兼ねて書こうと思います。
続きを読むインド出張
インドへ出張
iPXの鹿又です。
また出番が回ってきました。
iPXの私の所属するユニットでは、仕事柄、海外出張があります。
この間には、Kawaguchiさんがアメリカ出張に行ったことを書いていました。
これまで他の人も含め、フィリピン、インドネシア、台湾、ドイツ、アメリカ、中国への出張がありましたね。
いろんな人がいろんな場所に行くことがありますが、私は7月にインドに出張に行ってきました。
行った場所
出張先はインド南部 コインバトールというところで、あるサプライヤの開発部隊のあるところです。
成田空港より飛行機で8時間30分、デリーで一泊、国内線で3時間と、移動だけで20時間ぐらいの長旅になります。
公用語は英語が含まれるため、かなりのお年寄り以外は英語で話せました。
とはいっても、一緒に行った2名と私を含め、英語が堪能にできる人は1人もおらず、意思疎通に苦労するという状態でした。
サプライヤの日本人担当者に会うまでの間、「これはたどり着けるのか?」と心配になってしまいます。
ここに2週間、英語漬けの日々が始まります。
ホテルから撮った写真です
結構綺麗です
小観光
2週間の行程でしたので、土日を挟むわけです。
地元の人に案内いただいて小観光を楽しみました。
寺院
内部は撮影禁止
シヴァ神を祭った寺院
有名な寺院だそうですが、名前はよくわかりませんでした
ありがたいお祈りをいただく (インドの人がよく額に付ける灰と赤いもの)
沐浴場
自然公園に地元の人が使う沐浴場があるということで行ってみました
雨の後なので水量が多い
自然公園の看板
自然公園内
滝
沐浴場
サプライヤの日本人担当者が地元民と沐浴していました
地元の学生が「ネパール人か?」と聞くので「日本人だ」と答えると、やたら一緒に記念写真を撮られました。
おさるさん
人にとても慣れている (悪い意味で)
その他にも、カメレオンやらがいました。
野良象が見えるときもあるそうですが、運はよくなかったみたいです。
ヨガセンター
有名なヨガセンターに行ってみました。
もちろん、内部は撮影禁止
中は沐浴しながらヨガする場所や音厳禁で洞窟内でヨガする場所などがありました。
全員で洞窟内で座って瞑想するヨガをやりました
シヴァ神の大きな胸像 (入口付近)
ショッピングセンター
お土産を購入
ぞうさん
うしさん
地元の祭り
子供がある年齢になるとやる祭りだとか
街並み
食事とか
あまり食事の写真を撮りませんでした...
ほとんどはホテルで食事を採り、周辺で食べることはなかったです。
ホテルではビュッフェ形式。
だいたい毎日カレーだったので、日に日に皆が窶れていくのがわかります。
きっと日本人は本場のカレーから栄養は採れないようになっているのだと思います。
カレーとか
種類は豊富
南部ではライスが主食でナンはあまり食べない感じ
ドーサ
ちょっと酸味のあるクレープのようなもの
マサラとかつけて食べる
美味しい
デリー国際空港のラウンジでもカレーが......
「安全」と「安心」
約半年ぶりに登場します、加藤です。
今回は「安全」と「安心」について取り上げてみたいと思います。
はじめに
テスラの自動運転車(実際は自動運転ではなく運転支援機能なのですが)が死亡事故を起こしたり、豊洲市場の地下が空洞になっていたり、というニュースが世間を騒がせていますが、どうも一般向けのニュースでは安全と安心を混同したまま語られているように感じます。
では「安全」と「安心」の違いは何でしょうか?
この二つの言葉の意味を説明できますか?
弊社も製造業、特に自動車業界に関わる企業と仕事をさせて頂いていますので、正しく理解している必要があります。
「安全」と「安心」の違い
「安全」の定義はISOの中では用語として定義されています。
Safety
freedom from risk which is not tolerable
(許容できないリスクがないこと)Risk
combination of the probability of occurrence of harm and the severity of that harm
(危害の発生確率とその危害の重大性の組み合わせ)
(ISO/IEC Guideより引用 https://www.iso.org/obp/ui/#iso:std:iso-iec:guide:51:ed-3:v1:en)
ここで重要なのは「許容できないリスク」という表現でリスクの範囲を限定していることです。
リスクの定義も合わせて考えると、確率が低くて重大ではない危害まではカバーしていない、という事が分かります。
「安全」は「完全」ではないのがポイントです。
一方で「安心」については標準的な定義はありませんが、安全と対比しておおよそ以下のように定義されています。
安全:
- 客観的な事実
- 科学的に評価が可能
- 許容できないリスクがない状態
安心:
- 主観的な感情
- 科学的に(外部から)評価が出来ない
- リスクに対する寛容さは個人に依存する
安全はモノサシで測ることが可能ですが、安心は測ることが出来ない上に、安心かどうかの判断は完全に個人にゆだねられています。
「安心」できないのはなぜか?
上記の通り、安全と安心は異なる概念です。
多くの製造業ではISO規格などの品質マネジメントプロセスに則ることで「安全」を担保しています。
一方で一般の消費者にとって重要なのは「安心」です。
消費者に「安心」してもらうためには、製品を提供する側が「安全」であることを正しく説明することが必要です。
しかし、「安心」はは主観的な感情なので、全ての人に安心してもらうことは困難です。
なるべく多くの人に安心してもらうためには、以下のギャップを埋める事が必要となります。
その1:知識量のギャップ
ほぼ全ての事象において、説明する側は専門家であり、説明される側は素人です。
当然ながら、専門家と素人は持っている知識の量が異なる上に、素人の中でも知識量にもバラツキがあります。
また、
- 知識が無い人は、理解できないので不安に思わない
- ある程度知識がある人は、中途半端に理解するので不安度が高まる
- 十分な知識を持った人は、正しく理解できるので不安度は低い
といった傾向があるそうです。
その2:リスク感度のギャップ
安心と感じる基準は個人差があります。
さらに、特に不安度が高い人達には「ゼロリスクを求める」という傾向があります。
上記の「安全」の定義にあるように、基本的にリスクはゼロではありません。
想定できない範囲はもちろんですが、致命的でない問題については許容することがあります。
発生確率の非常に低い現象や危険度の低い現象など、小さなリスクまで対応するにはそれ相応のコストがかかります。
当然、そのコストは製品やサービスの価格にも反映されます。
この2つのギャップを埋めるためには、説明する側が相手のリテラシーを考慮した上で、説明の方法を工夫する必要があります。
消費者の安心を獲得するために
安心というのは信頼の上に成り立つもので、これらは一朝一夕で獲得できるものではありません。
日ごろから
- 正しい情報発信
- 的確な顧客サポート
- サービス、製品力の向上
に継続して取り組むことで、徐々に信頼感が蓄積されていくものです。
弊社では上記の取り組みの一つである「製品力の向上」を実現するための支援として、
- 開発プロセス全体の改善
- 新たな設計手法の導入
- 開発業務を支援する仕組み作り
をメニューとして取りそろえています。
SQLチューニング
SDU(System Development Unit)のタキヤマです
半年前にDB関係で何か記事を…と書いていましたが、
海老名/厚木で開催されていた某10周年のまつりが忙しい中
順番が迫っているのを知ったので、何の準備も無いまま書いてみようかと思います。
(まつりの記事書いたら突き返されるかな?)
…とはいったものの、チューニング関係だとやっぱり実際にDB作って計測しながらでないと書くのは難しいので
とりあえず今回はSQLに少し触れてみます。
これもDBの種類やバージョン、データの状態とかオプティマイザの実行計画等々…によって
何が最適なのかは変わってきてしまうのでこう書けば必ず早くなるといったものでもないです。
例えば以下のようなものがあります。
INよりEXISTSを使う ※Oracle, PostgreSQL除く
--【遅】 SELECT * FROM A WHERE A.id IN(SELECT B.id FROM B); --【早】 SELECT * FROM A WHERE EXISTS(SELECT * FROM B WHERE A.id = B.id);
EXISTSでは*を使う
--【遅】 SELECT * FROM A WHERE EXISTS(SELECT B.name FROM B WHERE A.id = B.id); --【早】 SELECT * FROM A WHERE EXISTS(SELECT * FROM B WHERE A.id = B.id);
COUNTはCOUNT(列)を使う ※Oracleを除く
--【遅】 SELECT COUNT(*) FROM A --【早】 SELECT COUNT(id) FROM A
WHERE句の列に対して演算や関数を使うとインデックスが使用できない
--【遅】 SELECT * FROM A WHERE num * 10 > 100 --【早】 SELECT * FROM A WHERE num > 100 / 10
ORはなるべくINを使う
--【遅】 SELECT * FROM A WHERE name = 'a' OR name = 'Bb' --【早】 SELECT * FROM A WHERE name IN ('a','b')
ORDER BY句では列番号を使わない
--【遅】 SELECT id, name FROM A ORDER BY 1 --【早】 SELECT id, name FROM A ORDER BY id
テーブルの結合は絞り込んでから行う
--【遅】 SELECT * FROM A, B WHERE A.id = B.id AND B.num > 100; --【早】 SELECT * FROM A, (SELECT * FROM B WHERE B.num > 100) C WHERE A.id = C.id;
などなどなどなど
書ききれないくらい色々あったりします。
では最後に
こんな3つのテーブルがあるとします。
主キー、外部キー以外にインデックスは作成しないものとします。
※SQLは標準SQLでは無くOracle準拠です
CREATE TABLE item ( item_id NUMBER PRIMARY KEY , item_name VARCHAR(40) , price NUMBER ); CREATE TABLE customer ( cstmr_id NUMBER PRIMARY KEY , cstmr_name VARCHAR(40) , age NUMBER ); CREATE TABLE order ( order_id NUMBER PRIMARY KEY , item_id NUMBER , cstmr_id NUMBER , order_date DATETIME , FOREIGN KEY (item_id) REFERENCES item (item_id) , FOREIGN KEY (cstmr_id) REFERENCES customer (cstmr_id) );
20代の20時~22時の注文のうち、新しいものから順に1000件の中で
売上合計が高い商品順に並べる。
これを以下のようなSQLで検索しようとしたところ
想定していたよりもレスポンスが悪い結果となりました。
ではこのSQLをどのように書き換えたらレスポンスが改善できるでしょうか?
SELECT NarrowOrder.item_name as "商品名" , COUNT(*) as "売上件数" , SUM(NarrowOrder.price) as "売上合計" FROM ( SELECT item_name , price FROM ( SELECT item.item_name , item.price FROM order , customer , item WHERE customer.cstmr_id = order.cstmr_id AND item.item_id = order.item_id AND customer.age >= 20 AND customer.age < 30 AND TO_CHAR(order.order_date, 'hh24:mi:ss') >= '20:00:00' AND TO_CHAR(order.order_date, 'hh24:mi:ss') < '22:00:00' ORDER BY order.order_id DESC ) WHERE ROWNUM >= 1000 ) NarrowOrder GROUP BY NarrowOrder.item_name ORDER BY 3 DESC ;
以下のSQLは一例となりますが、
おそらく先程のSQLと比較すると、
データ量が多ければ多いほどはっきりと差が出てくると思われます。
(実際に試してはいないので説得力は弱いですが)
SELECT item.item_name as "商品名" , COUNT(*) as "売上件数" , SUM(item.price) as "売上合計" FROM ( SELECT item_id FROM ( SELECT item_id FROM order WHERE cstmr_id in ( SELECT cstmr_id FROM customer WHERE age >= 20 AND age < 30 ) AND TO_NUMBER(TO_CHAR(order.order_date, 'hh24miss')) BETWEEN 200000 AND 220000 ORDER BY order_id DESC ) WHERE ROWNUM >= 1000 ) NarrowOrder JOIN item ON NarrowOrder.item_id = item.item_id GROUP BY item.item_name ORDER BY SUM(item.price) DESC ;
※1000件の絞込みはOracle12cからインラインビューでROWNUMを使わなくとも
Order by句の次に「FETCH FIRST 1000 ROWS ONLY」と記載することも出来ます。
ポイントはデータの絞込みと結合の順番になります。
まずはユニークなデータであるcustomerを絞り込んでおき、
対象のデータを減らした上でorderと結合しています。
また、itemの結合をデータ件数の一番多いであろうorderでは無く、
検索条件を満たした上で1000件に絞った状態のNarrowOrderに対して行うようにしています。
注文時間の絞込みについては文字列で行わず、数値で行うようにし、かつBETWEENを使用するようにしています。
※インデックスを作成する場合はorderテーブルにcstmr_idとorder_dateの複合インデックスを作りヒント句で強制、日付型のままBETWEENを使わない方が早くなります
と、ここまで書いてみましたが、実際にはコストベースオプティマイザだと
しばらく使っているうちに統計情報からどんな実行計画が作られるかにもよってくるので
実践でのチューニングは色々と手間が掛かってくるわけです。
次回順番が回ってきた時は、実際のDBを使用したチューニングでもやってみようかと思います(たぶん)
あ、そろそろ今シーズンのスノボ旅行の予約もしないと…
今回も雪まつりと重なりそうなので、次回更新が北海道日記にならないように気を付けます
Abaqus CAEで会社ロゴを自動でメッシュ分割する
EPLU(Engineering Process Leading Unit)のパルハットです。
以前仕事現場でCAE関連の業務に関わりました。今回それに関係する内容で書こうと思います。
CAE関連のソフトはたくさんありますが、今回はAbaqus14 Student Editionを使用して、簡単な会社ロゴ(iPXの文字)のメッシュをスクリプトで作ります。
Abaqusはスクリプト言語としてPython2.6を使用できます。Pythonは完全にオブジェクト指向の構造です。
AbaqusではPythonオブジェクトとしてSession, Mdb, Odbが提供されています。SessionオブジェクトにはViewportの定義、リモートキュー、ユーザ定義Views等を含みます。
Mdbオブジェクトはモデル情報を含みます。Odbオブジェクトは解析結果データ関連情報を含みます。プログラム作成手順は以下のとおりです。
- 初期定義とモデル定義
- 2次元スケッチ作成
- パート作成
- アセンブリ設定
- メッシュ作成
初期定義とモデル定義
from abaqus import * from abaqusConstants import * from caeModules import * # モデルオブジェクトの作成 Mdb() mdl = mdb.Model(name="Model-iPXLogo")
2次元スケッチ作成
# 2次元スケッチ作成 stk = mdb.models['Model-iPXLogo'].ConstrainedSketch(name='Sketch iPX', sheetSize=200.0) # i字の作成 # 指定座標に円を作成 stk.CircleByCenterPerimeter(center=(-12.5, 10.0), point1=(-10.0, 10.0)) #指定座標に長方形を作成 stk.rectangle(point1=(-15.0, 5.0), point2=(-10.0, -17.5)) # P字の作成 xyCoords=[[6.25, 12.5],[-5.0, 12.5],[-5.0, 12.5],[-5.0, -17.5],[-5.0, -17.5], [0.0, -17.5],[0.0, -17.5],[0.0, -2.5],[0.0, -2.5],[6.25, -2.5], [0.0, 2.5], [5.0, 2.5], [0.0, 2.5], [0.0, 7.5], [0.0, 7.5], [5.0, 7.5]] for i in range(0, len(xyCoords) - 1, 2): stk.Line(point1=xyCoords[i], point2=xyCoords[i+1]) stk.Arc3Points(point1=(5.0, 7.5), point2=(5.0, 2.5), point3=(7.5, 5.0)) stk.Arc3Points(point1=(6.25, 12.5), point2=(6.25, -2.5), point3=(12.5, 5.0)) # X字の作成 xyCoords1=[[15.0, 12.5],[23.75, -2.5],[23.75, -2.5],[15.0, -17.5],[15.0, -17.5],[20.0, -17.5], [20.0, -17.5],[27.5, -5.0],[15.0, 12.5],[20.0, 12.5],[20.0, 12.5],[27.5, 0.0], [27.5, 0.0],[35.0, 12.5],[35.0, 12.5],[40.0, 12.5],[40.0, 12.5],[31.25, -2.5], [31.25, -2.5],[40.0, -17.5],[40.0, -17.5],[35.0, -17.5],[35.0, -17.5],[27.5, -5.0]] for i in range(0, len(xyCoords1) - 1, 2): stk.Line(point1=xyCoords1[i], point2=xyCoords1[i+1])
作成されたスケッチ図は以下の通りです。
パート作成
#パートを作成します。 p = mdb.models['Model-iPXLogo'].Part(name='iPXLogo', dimensionality=THREE_D, type=DEFORMABLE_BODY) p = mdb.models['Model-iPXLogo'].parts['iPXLogo'] p.BaseSolidExtrude(sketch=stk, depth=5.0) session.viewports['Viewport: 1'].setValues(displayedObject=p)
作成されたパート図は以下の通りです。
アセンブリ設定
# アセンブリにパートをインスタンス化します。 iPXAssambely = mdb.models['Model-iPXLogo'].rootAssembly iPXInstance = iPXAssambely.Instance(name="iPXLogo A-1", part=p, dependent=OFF)
作成されたアセンブリ図は以下の通りです。
メッシュ作成
# メッシュを作成します。 partInstances = [iPXInstance] iPXAssambely.seedPartInstance(regions=partInstances, size=2.0) iPXAssambely.generateMesh(regions=partInstances) # viewportでメッシュインスタンスを表示します。 iPXViewport = session.Viewport(name="ipx viewport", origin=(10,10), width=400, height=200) iPXViewport.assemblyDisplay.setValues(renderStyle=SHADED, mesh=ON) iPXViewport.setValues(displayObject=iPXAssambely)
作成されたメッシュ図は以下の通りです。
まとめ
今回Abaqusを使用して簡単なロゴを作成して、メッシュまで作りました。メッシュサイズをもっと小さくすると、刻みがきれいに出来ます。
次回は材料情報の追加と何らかの境界条件を追加して、解析コンター図まで出してみたいです。
参考情報
- http://www.jikosoft.com/cae/abaqus/index.html
- Abaqus14 Student Editionドキュメント(インストール時に一緒にインストールされます。)
■
どうも。VFDU(Vehicle Function Development Unit)のカワグチです。
先日海外へ出張させていただいたので、その時の運転訓練の話をば少々。
写真と一緒に振り返ってみます。
初めての海外出張inアメリカ
ことの始まりは上長からの依頼。
業務としてアメリカ合衆国オハイオ州へ出張してほしいと打診があり、
私と同僚の二人で渡米することとなりました。
宿泊先はオハイオ州のとある街のホテル。
出張先は街はずれにある建屋でした。
ホテルから建屋まで自動車で60分程度かかり車での移動が必要不可欠なため、
レンタカーを借り、不慣れな右側通行・左ハンドル車両の運転訓練(慣らし運転)を行いました。
運転中に驚いたこと
・とにかく道路が広い
一般道もフリーウェイもアメリカサイズでした。
・とにかく道路が真っ直ぐ
特にフリーウェイはとにかく直線(と緩いカーブ)で長距離運転しても疲れませんでした。
・フリーウェイが無料
日本の高速道路のように料金を支払ったりしません。うらやましい!
・速度はマイル表示
アメリカなので当たり前ですが、車の速度メーターの表示がマイルでした。
フリーウェイは70mph(≒112km/h) 制限の箇所が多かったです。
・赤信号でも右折可
他車両が接近していない等、安全であれば赤信号でも右折することができます。
※ただし「NO TURN ONRED」の標識がある場合は赤信号時の右折禁止。
・果てしなく続くトウモロコシ畑
映画で観たことあるやつ
・ノーヘルライダー
映画で観たことあるやつ
※オハイオ州では基本的に18才以下のみ要。詳細は下記参照。
所感
今までほとんど海外に行ったことがなく苦手意識がありましたが、
今回ありがたいことにお仕事で海外経験をさせていただきました。
おっかなびっくりの海外出張でしたが、
日本と比べて良いところ悪いところを発見するという楽しみを知れて良い勉強になりました。
次はプライベートで海外旅行というのも悪くないと思います。
最後に、出張中に色々対応して下さった方々、出張先でお世話になった皆様、ブログを読んで下さった読者様、どうもありがとうございました。
参考URL
車でアメリカを走るために必要なもの、交通ルール
abroad.driver.jp
www5b.biglobe.ne.jp
アメリカバイク事情
アメリカツーリング情報/交通規制ガイド/ヘルメット規制 - WWW.NPNY.COM
おまけ(オハイオの食事)
大学入試における物理問題の解き方
お初にお目にかかります。2016年4月入社の高橋です。
今回は、私が大学受験をしていた時にやっていた物理の解き方について書いていこうと思います。
このテーマを選んだ理由は後で出てきます。
高校教育課程の物理
普通高校で習う物理は、いろいろな法則や方程式などを学んでいくと思います。
例えば、hの高さにあるボールを自由落下させたときのt秒後の状態について考えます。
そのときボールは上向きを正として
・v=-gt
・x=h-1/2*gt^2
もしくは、速さv0で地上から鉛直投げ上げしたボールのt秒後は
・v=v0-gt
・x=v0t-1/2*gt^2
・v^2-v0^2=2gx
といったような状態が求まります。
高校ですとこれらを「覚えさせられます」。。。
こういうのあまりよろしくないと思うんですよね。
最初物理に触れるときにこういう入り方(微積のカリキュラムも考慮されて)なのは良いと思うのですが、受験物理を解くにあたって方程式を暗記して使うみたいなのだと到底太刀打ちできません。
こういう考え方のままでいると、ちょっと複雑になるとたぶんすぐ思考が止まってしまうんじゃないかと思います。
しかし、過去の偉人たちが観測を元に割り出した基本法則などは覚えなければなりません。
なぜならなにかから計算したわけではないので、様々なアプローチの元になります。四則演算のようなものです。
要するに私が言いたいのは
「覚えることは少なくして楽をしよう」
ということです。
問題へのアプローチ
「図を描け」
短いです。短いですけど大事なことです。
こちらは塾の先生が物理を解くときに大事にしていたことです。
大学入試の問題として出てくる大部分は古典力学です。
図を描いて解けるようになれば力学、電磁気系統の問題はかなり楽に解けるかと思います。
波動系とか量子系に関しては微妙かもしれません。
それでは具体的にどのような図を描けばいいのでしょうか。
下の図を見てください。
これは重力加速度のある空間で自由運動する物体を考えます。
物体にかかっている外力は重力のみです。
ここで注意する点として、問題を解く人が設定する変数は必ず「軸の正の方向」に対して正と置くようにしましょう。
上向きを正としてる時に下向きの加速度を設定すると、符号の処理が一気にややこしくなります。
図を描いたらやることは簡単で、1方向もしくは直交する2方向に関して運動方程式や力の釣り合いを見ます。
運動方程式とはma=Fです。物理を始めるとき習う最も基本的な方程式です。今回は鉛直方向に当てはめると
・ma=-mg
が方程式となります。
簡単ですね。
このように方程式さえ導出してしまえば、あとは方程式を連立していけば未知数は導き出せます。
両辺をmで割れば加速度aを求めることもできます。
・a=-g
加速度が求まったので積分を行えば
・v=-gt+v0
・x=-1/2*gt^2+v0t+x0
となり速さと変位が求まります。v0,x0は初期値です。
ちなみにこのとき加速度aの設定を軸の向きと逆にすると
d^2x/dt^2=-a
となりすこし面倒です。
次の例を見ていきましょう。
こちらは摩擦の発生する坂の上に物体が静止している状態です。
今回は重力に加え、坂からの垂直抗力と静止摩擦力が加わっています。
先に書いた自由運動とは違い、物体にかかる外力が同軸上にありません。
こういう時は直交2成分に分割して考察します。
どのような2成分を取るかは問題によります。
どのように分けようと答えは導き出せますが、計算の分量は大きく変わります。
今回は坂に対して平行・垂直でとります。こういう問題は坂の上を運動する問題にも発展するので、変数の設定上こちらが楽です。
ただ下の土台が固定じゃない場合は、加速度の設定などで水平・鉛直の方が良かったりしますがそれはまた別の機会にお話しします。
重力を坂の角度θで分解できたので、それぞれの釣り合いの式を見ます。
・mgsinθ=μN
・N=mgcosθ
となります。
最初に「図を描け」と書きましたが、それとセットで図から運動方程式や力のつりあいなどを書き出すことが大切です。
逆に言うとそれをするだけで大概の問題は解けます。
仕事における活躍
さて、わたしがなぜこの題材をブログ記事に選んだかについて触れようかと思います。
今私がかかわっているモデルベース開発というものがあるのですが、ここで使われるModelica言語でこの考え方が有用になってくるのです。
Modelicaはオブジェクト指向言語であり、特徴として非因果的な記述が行えます。
どういうことかというと、(微分)方程式を複数記述すると、それらを連立して求める変数の時間変化が得られるのです。
このように、物理現象を抽象化した図を描き方程式を書き出すということができれば、それをそのままModelicaで記述し計算できるのです。
まとめ
物理現象を解くときには
・図を描く
・方程式を書き出す
の二つを意識しましょう。これだけで大学入試の物理は解けます。
特にめんどくさい誘導にしただけの問題とかはすぐに解けます。
また、物体に働く力をきちんと把握し書き出す技術は、物理現象の理解をより深める助けにもなるので活用しましょう。
次回出番が回ってきたときには、図の描き方を掘り下げるか問題を解いてみるかモデルベース開発に触れていくかを使用と思います。