پاسخ_به_سوال
#ارور
#relative_tolerance
#کامسول
[بخش سوم]
ز) در مورد مسایل غیرخطی و وابسته به زمانی مانند آنالیز موج، الکترومغناطیس، تنش های تانسوری غیرخطی، و مانند آن که دقت حل مساله بشدت وابسته به کیفیت مش ریزی روی فیزیک موج است، حل دستگاه معادلات موج وابسته به زمان با تعریف قید هایی روی time step های مورد استفاده در الگوریتم حل ممکن می شود. بطورکلی، امکان اینکه کاربر کامسول بتواند به تعادل لازم بین دقت نتایج و پایدار سازی الگوریتم حل چنین مسایل غیرخطی از طریق دستکاری در تنظیمات حلگر دست پیدا کند، وجود دارد. آنچه که در مورد این مسایل اهمیت دارد آنست که کاربر کامسول اصلا تشخیص دهد که اصلا چه سایز مشی برای مساله او مناسب است؟ پاسخ به این سوال نسبتا ساده است: درست مثل دامنه فرکانسی یا frequency domain، برای هر طول موج به تقریبا 5 (پنج) المان مش مرتبه دوم نیاز است. لازم بذکر است که در یک مساله دامنه زمانی (time domain)، موج مورد مطالعه در مساله تنها از یک فرکانس واحد برخوردار نبوده و مقدار فرکانسی آن بصورت یک طیف فرکانسی قابل بیان است. بعنوان مثال، مدلی را در نظر بگیرید که از پالس های گائوسی با انحراف معیار sqr(2)/(2*pi*f0) برخوردار باشد. در این حالت، بخش اعظم انرژی هر پالس (یعنی چیزی در حدود 95.5%) روی فرکانس های کمتر از f0 توزیع خواهد شد. بدین ترتیب، اگر بخواهیم بر مشکل ناشی از این فرکانس های مزاحم غلبه کنیم، باید حداکثر سایز مش را روی h0=c/(N*f0) تنظیم کنیم. در این شرط سایز، حرف c نماینده سرعت موضعی نور یا صوت بوده و N نیز نشاندهنده تعداد المان های مش روی هر طول موج است (همان N=5). اکنون باید بدنبال تایم استپی بگردیم که موج را بصورت مساوی در زمان تعریف کند. درست همانند مش که در مکان تعریف می کرد. واضح است که تایم استپ های خیلی بلند تناسب خوبی با تعداد مش ریخته شده روی مدل برقرار نمی کنند و از طرف مقابل، تایم استپ های خیلی کوتاه نیز تنها منجر به تطویل زمان حل خواهند شد...بدون اینکه روی دقت نتایج تاثیر قابل توجهی بگذارند. اینجاست که با مفهومی در کامسول با عنوان CFL مواجه می شویم. CFL رابطه بین سایز مش و طول تایم استپ است و با این فرمول تعریف می شود:
CFL=c*delta(t)/ h
که در آن، delta(t) بیانگر تایم استپ و h نماینده سایز مش است. مطابق تجربیات کسب شده، با مقدار N=5 برای تعداد المان های روی هر طول موج، عملا به مقدار CFL=0.2 خواهیم رسید که برای بسیاری از مسائل کافی است.
در حالت پیش فرض، حلگر تایم دیپندنت دائما مقادیر تایم استپ را برای تطابق با تلرانس های تعریف شده توسط کاربر کامسول تنظیم می کند. اما، در صورتیکه تئوری مساله را قبلا بخوبی مطالعه کرده اید و با توجه به توضیحاتی که بالاتر داده شد، می دانید که دقیقا به چه تایم استپی نیاز دارید، بهتر است مقدار آن را بصورت دستی به کامسول بدهید. برای اینکار، ابتدا روی نود Study راست کلیک کرده و Show Default Solver را انتخاب کرده و سپس روی تب Settings در نود Time-Dependent Solver کلیک کنید. نکته ای که در آخر لازم به ذکر می دانم آنست که تغییر مقدار times خروجی در نود Step 1: Time Dependent منجر به تغییر زمان های خروجی (output times) می شود که تاثیر اندکی روی تایم استپ هایی که حلگر تنظیم می کند، دارد.
@comsol_shs
#ارور
#relative_tolerance
#کامسول
[بخش سوم]
ز) در مورد مسایل غیرخطی و وابسته به زمانی مانند آنالیز موج، الکترومغناطیس، تنش های تانسوری غیرخطی، و مانند آن که دقت حل مساله بشدت وابسته به کیفیت مش ریزی روی فیزیک موج است، حل دستگاه معادلات موج وابسته به زمان با تعریف قید هایی روی time step های مورد استفاده در الگوریتم حل ممکن می شود. بطورکلی، امکان اینکه کاربر کامسول بتواند به تعادل لازم بین دقت نتایج و پایدار سازی الگوریتم حل چنین مسایل غیرخطی از طریق دستکاری در تنظیمات حلگر دست پیدا کند، وجود دارد. آنچه که در مورد این مسایل اهمیت دارد آنست که کاربر کامسول اصلا تشخیص دهد که اصلا چه سایز مشی برای مساله او مناسب است؟ پاسخ به این سوال نسبتا ساده است: درست مثل دامنه فرکانسی یا frequency domain، برای هر طول موج به تقریبا 5 (پنج) المان مش مرتبه دوم نیاز است. لازم بذکر است که در یک مساله دامنه زمانی (time domain)، موج مورد مطالعه در مساله تنها از یک فرکانس واحد برخوردار نبوده و مقدار فرکانسی آن بصورت یک طیف فرکانسی قابل بیان است. بعنوان مثال، مدلی را در نظر بگیرید که از پالس های گائوسی با انحراف معیار sqr(2)/(2*pi*f0) برخوردار باشد. در این حالت، بخش اعظم انرژی هر پالس (یعنی چیزی در حدود 95.5%) روی فرکانس های کمتر از f0 توزیع خواهد شد. بدین ترتیب، اگر بخواهیم بر مشکل ناشی از این فرکانس های مزاحم غلبه کنیم، باید حداکثر سایز مش را روی h0=c/(N*f0) تنظیم کنیم. در این شرط سایز، حرف c نماینده سرعت موضعی نور یا صوت بوده و N نیز نشاندهنده تعداد المان های مش روی هر طول موج است (همان N=5). اکنون باید بدنبال تایم استپی بگردیم که موج را بصورت مساوی در زمان تعریف کند. درست همانند مش که در مکان تعریف می کرد. واضح است که تایم استپ های خیلی بلند تناسب خوبی با تعداد مش ریخته شده روی مدل برقرار نمی کنند و از طرف مقابل، تایم استپ های خیلی کوتاه نیز تنها منجر به تطویل زمان حل خواهند شد...بدون اینکه روی دقت نتایج تاثیر قابل توجهی بگذارند. اینجاست که با مفهومی در کامسول با عنوان CFL مواجه می شویم. CFL رابطه بین سایز مش و طول تایم استپ است و با این فرمول تعریف می شود:
CFL=c*delta(t)/ h
که در آن، delta(t) بیانگر تایم استپ و h نماینده سایز مش است. مطابق تجربیات کسب شده، با مقدار N=5 برای تعداد المان های روی هر طول موج، عملا به مقدار CFL=0.2 خواهیم رسید که برای بسیاری از مسائل کافی است.
در حالت پیش فرض، حلگر تایم دیپندنت دائما مقادیر تایم استپ را برای تطابق با تلرانس های تعریف شده توسط کاربر کامسول تنظیم می کند. اما، در صورتیکه تئوری مساله را قبلا بخوبی مطالعه کرده اید و با توجه به توضیحاتی که بالاتر داده شد، می دانید که دقیقا به چه تایم استپی نیاز دارید، بهتر است مقدار آن را بصورت دستی به کامسول بدهید. برای اینکار، ابتدا روی نود Study راست کلیک کرده و Show Default Solver را انتخاب کرده و سپس روی تب Settings در نود Time-Dependent Solver کلیک کنید. نکته ای که در آخر لازم به ذکر می دانم آنست که تغییر مقدار times خروجی در نود Step 1: Time Dependent منجر به تغییر زمان های خروجی (output times) می شود که تاثیر اندکی روی تایم استپ هایی که حلگر تنظیم می کند، دارد.
@comsol_shs
#اطلاع_رسانی
#آموزش
#کامسول
پس از اتمام پست مربوط به بررسی علل بروز ارور Relative Tolerance، مبحث مهمی در آموزش نحوه کار با کامسول در حل مسائل CFD را شروع خواهیم کرد که به بیان تفارت دو تکنیک Level Set و Phase Field اختصاص دارد.
این مبحث آموزش COMSOL از چند بخش تشکیل می شود که به مرور و با اتمام هر بخش، در کانال آپلود خواهد شد.
#آموزش
#کامسول
پس از اتمام پست مربوط به بررسی علل بروز ارور Relative Tolerance، مبحث مهمی در آموزش نحوه کار با کامسول در حل مسائل CFD را شروع خواهیم کرد که به بیان تفارت دو تکنیک Level Set و Phase Field اختصاص دارد.
این مبحث آموزش COMSOL از چند بخش تشکیل می شود که به مرور و با اتمام هر بخش، در کانال آپلود خواهد شد.
#بلاگ
#آموزش
#توربوشارژر
#روتوردینامیک
#فرکانس
#کامسول
@comsol_shs
برای مخاطبینی که علاقمند به تحلیل و محاسبات روتوردینامیک (شامل آنالیز Eigenfrequency و آنالیز پاسخ فرکانسی) توربوشارژرها و شبیه سازی آنها با کامسول هستند، مطالعه بلاگ زیر توصیه می شود:
https://www.comsol.com/blogs/evaluating-a-turbocharger-design-with-rotordynamics-analysis/
در عین حال، فایل های هندسه توربوشارژر و مساله حل شده در این بلاگ در ذیل تقدیم شده است👇🏻👇🏻👇🏻
@comsol_shs
#آموزش
#توربوشارژر
#روتوردینامیک
#فرکانس
#کامسول
@comsol_shs
برای مخاطبینی که علاقمند به تحلیل و محاسبات روتوردینامیک (شامل آنالیز Eigenfrequency و آنالیز پاسخ فرکانسی) توربوشارژرها و شبیه سازی آنها با کامسول هستند، مطالعه بلاگ زیر توصیه می شود:
https://www.comsol.com/blogs/evaluating-a-turbocharger-design-with-rotordynamics-analysis/
در عین حال، فایل های هندسه توربوشارژر و مساله حل شده در این بلاگ در ذیل تقدیم شده است👇🏻👇🏻👇🏻
@comsol_shs
COMSOL
Evaluating a Turbocharger Design with Rotordynamics Analysis
If a turbocharger in an engine fails, it can cause a fire. Use simulation to analyze the performance of a turbocharger design under cross-coupled bearing forces.
#در_خانه_بمانیم
#کرونا پشت در خانه شما در کمین است...در کوچه، بازار، اداره، بانک، خیابان، و...
این قاتل اسیر نمی گیرد! بی صدا می کشد!
به اشتراک گذاشته شده از طرف جناب دکتر فاتحی
@comsol_shs
#کرونا پشت در خانه شما در کمین است...در کوچه، بازار، اداره، بانک، خیابان، و...
این قاتل اسیر نمی گیرد! بی صدا می کشد!
به اشتراک گذاشته شده از طرف جناب دکتر فاتحی
@comsol_shs
Media is too big
VIEW IN TELEGRAM
ویدئوی آموزشی
موضوع:
Setting Up and Running a Simulation with COMSOL Multiphysics®
مدت: 46 دقیقه و 18 ثانیه
حجم: 103MB
فرمت: MP4
@Comsol_shs
موضوع:
Setting Up and Running a Simulation with COMSOL Multiphysics®
مدت: 46 دقیقه و 18 ثانیه
حجم: 103MB
فرمت: MP4
@Comsol_shs
#پاسخ_به_سوال
#ارور
#MUMPS
با سلام و احترام
با توجه به سوال واصله در خصوص بروز اروری با متن MUMPS out-of-core، در ذیل به بررسی دلایل احتمالی و راهکار های مناسب برای غلبه بر این ارور پرداخته ایم:
معمولا حلگر MUMPS بمنظور همگرایی الگوریتم حل از تمامی منابع درون هسته ای یا in-core سیستم کامپیوتر (یا لپ تاپ) استفاده می کند. این ارور زیرمجموعه ارور های out-of-memory قرار می گیرد که به اتمام منبع پردازش کامپیوتر و در خطر قرار گرفتن ظرفیت حافظه موقت یک سیستم یا RAM اشاره دارد. بدین ترتیب، و در اینجا، وقتی حلگر MUMPS تشخیص می دهد که ظرفیت RAM در خطر قرار گرفته (با توجه به حاشیه امنی که در CPU تعریف شده) روند حل را متوقف کرده و پیغام فوق را نشان می دهد. بعنوان مثال، فرض کنید برای حل یک مساله در کامسول نیاز به 30GB از حافظه RAM با توسل به حلگر MUMPS باشد، در حالیکه ظرفیت اسمی RAM سیستم 24GB است. در این شرایط، حلگر MUMPS مقداری از کار را که جلو رفت، کم کم کند شده و حل را متوقف می کند. سپس پیغام کذایی فوق به نمایش درمی آید. اما، اگر RAM مورد نیاز بجای 30GB، به 20GB کاهش یابد، حلگر MUMPS حل را شروع کرده و به اتمام می رساند (هرچند به کندی).
حال، یکی از راهکارهای استانداردی که برای غلبه بر این مشکل وجود دارد، استفاده از In-core memory (MB) (چک باکس) در تنظیمات حل MUMPS است. با اینکار، کامسول الگوریتم حل MUMPS را ملزم به استفاده از disk RAM بمنظور حل مساله می نماید. این بدان معنی است که در مثال فوق (30 گیگ رم لازم و 24 گیگ موجود) با تیک زدن در چک باکس In-core memory (MB)، احتمال بروز خطای MUMPS out-of-core کمتر می شود. ولی به صفر نمی رسد!
نکته ای که لازم است در اینجا ذکر شود آن است که پس از تیک زدن چک باکس In-core memory (MB)، باید میزان استفاده از منابع disk RAM برای حلگر MUMPS مشخص شود. این مشخص سازی یک تکنیک هوشمندانه از طرف کاربر است...چراکه تجربه نشان داده که اتخاذ مقادیر بالا صرفا به معنای راه انداختن هرچه بهتر کار نیست!
به مثال فوق برمی گردیم: فرض کنید کاربر کامسول تیک In-core memory (MB) را فعال کرده و اجازه برداشت از حافظه را به میزان 8GB به کامسول می دهد. این یعنی حلگر MUMPS اجازه دارد باندازه 8GB از حافظه in-core استفاده کرده و باندازه 22GB از disk RAM برای حل مساله بردارد. اینطوری، احتمال بروز خطای MUMPS out-of-core کمتر می شود. اما به صفر نمی رسد...چراکه ممکن است این خطا دوباره ظاهر شود. چرا؟! خب معلوم است! سایر بخش های کامسول نیز به RAM نیاز دارند و غیر از آن، برنامه ها و نرم افزارهای جاری ویندوز نیز هستند که باندازه نیاز خود (نه بصورت مداوم) به برداشت از RAM نیاز دارند. بنابراین، واقعا اینکه چه عددی را پس از زدن تیک In-core memory (MB) وارد تنظیمات حلگر MUMPS کنید، هیچکس نمی داند و ممکن است از یک مساله به مساله و از یک کامپیوتر (حتی!) تا یک کامپیوتر دیگر (حتی بغل دستی اش!) فرق کند.
تجربه شخصی من آنست که استفاده از این آپشن (یعنی تیک زدن در چک باکس In-core memory (MB) و دادن عددی برای اجازه دادن به کامسول برای برداشت از disk RAM) منجر به کندی شدید روند حل شده و زمان حل را بسیار بالا می برد که بنظر من ارزشش را ندارد. تجربه شخصی من پناه بردن به حلگرهای دیگری مانند PARADISO را نیز رد میکند. چراکه در آنجا نیز آسمان همین رنگ است!
خب پس اگر پیغام ارور MUMPS out-of-core را دیدیم، چاره چیست؟ بهترین راه حل در این مورد، به ترتیب، عبارتند از کاهش سایز مساله (تعداد DOF را کاهش دهید)، اضافه کردن RAM به سیستم (حتی تا دو برابر کردن را امتحان کرده ام!)، و در آخر: parallel processing...البته، استفاده از تکنیک هایی مانند allocation factor که قبلا توضیح داده بودم در این کانال نیز می تواند کارساز باشد...اما، معجزه نمی کند.
#ارور
#MUMPS
با سلام و احترام
با توجه به سوال واصله در خصوص بروز اروری با متن MUMPS out-of-core، در ذیل به بررسی دلایل احتمالی و راهکار های مناسب برای غلبه بر این ارور پرداخته ایم:
معمولا حلگر MUMPS بمنظور همگرایی الگوریتم حل از تمامی منابع درون هسته ای یا in-core سیستم کامپیوتر (یا لپ تاپ) استفاده می کند. این ارور زیرمجموعه ارور های out-of-memory قرار می گیرد که به اتمام منبع پردازش کامپیوتر و در خطر قرار گرفتن ظرفیت حافظه موقت یک سیستم یا RAM اشاره دارد. بدین ترتیب، و در اینجا، وقتی حلگر MUMPS تشخیص می دهد که ظرفیت RAM در خطر قرار گرفته (با توجه به حاشیه امنی که در CPU تعریف شده) روند حل را متوقف کرده و پیغام فوق را نشان می دهد. بعنوان مثال، فرض کنید برای حل یک مساله در کامسول نیاز به 30GB از حافظه RAM با توسل به حلگر MUMPS باشد، در حالیکه ظرفیت اسمی RAM سیستم 24GB است. در این شرایط، حلگر MUMPS مقداری از کار را که جلو رفت، کم کم کند شده و حل را متوقف می کند. سپس پیغام کذایی فوق به نمایش درمی آید. اما، اگر RAM مورد نیاز بجای 30GB، به 20GB کاهش یابد، حلگر MUMPS حل را شروع کرده و به اتمام می رساند (هرچند به کندی).
حال، یکی از راهکارهای استانداردی که برای غلبه بر این مشکل وجود دارد، استفاده از In-core memory (MB) (چک باکس) در تنظیمات حل MUMPS است. با اینکار، کامسول الگوریتم حل MUMPS را ملزم به استفاده از disk RAM بمنظور حل مساله می نماید. این بدان معنی است که در مثال فوق (30 گیگ رم لازم و 24 گیگ موجود) با تیک زدن در چک باکس In-core memory (MB)، احتمال بروز خطای MUMPS out-of-core کمتر می شود. ولی به صفر نمی رسد!
نکته ای که لازم است در اینجا ذکر شود آن است که پس از تیک زدن چک باکس In-core memory (MB)، باید میزان استفاده از منابع disk RAM برای حلگر MUMPS مشخص شود. این مشخص سازی یک تکنیک هوشمندانه از طرف کاربر است...چراکه تجربه نشان داده که اتخاذ مقادیر بالا صرفا به معنای راه انداختن هرچه بهتر کار نیست!
به مثال فوق برمی گردیم: فرض کنید کاربر کامسول تیک In-core memory (MB) را فعال کرده و اجازه برداشت از حافظه را به میزان 8GB به کامسول می دهد. این یعنی حلگر MUMPS اجازه دارد باندازه 8GB از حافظه in-core استفاده کرده و باندازه 22GB از disk RAM برای حل مساله بردارد. اینطوری، احتمال بروز خطای MUMPS out-of-core کمتر می شود. اما به صفر نمی رسد...چراکه ممکن است این خطا دوباره ظاهر شود. چرا؟! خب معلوم است! سایر بخش های کامسول نیز به RAM نیاز دارند و غیر از آن، برنامه ها و نرم افزارهای جاری ویندوز نیز هستند که باندازه نیاز خود (نه بصورت مداوم) به برداشت از RAM نیاز دارند. بنابراین، واقعا اینکه چه عددی را پس از زدن تیک In-core memory (MB) وارد تنظیمات حلگر MUMPS کنید، هیچکس نمی داند و ممکن است از یک مساله به مساله و از یک کامپیوتر (حتی!) تا یک کامپیوتر دیگر (حتی بغل دستی اش!) فرق کند.
تجربه شخصی من آنست که استفاده از این آپشن (یعنی تیک زدن در چک باکس In-core memory (MB) و دادن عددی برای اجازه دادن به کامسول برای برداشت از disk RAM) منجر به کندی شدید روند حل شده و زمان حل را بسیار بالا می برد که بنظر من ارزشش را ندارد. تجربه شخصی من پناه بردن به حلگرهای دیگری مانند PARADISO را نیز رد میکند. چراکه در آنجا نیز آسمان همین رنگ است!
خب پس اگر پیغام ارور MUMPS out-of-core را دیدیم، چاره چیست؟ بهترین راه حل در این مورد، به ترتیب، عبارتند از کاهش سایز مساله (تعداد DOF را کاهش دهید)، اضافه کردن RAM به سیستم (حتی تا دو برابر کردن را امتحان کرده ام!)، و در آخر: parallel processing...البته، استفاده از تکنیک هایی مانند allocation factor که قبلا توضیح داده بودم در این کانال نیز می تواند کارساز باشد...اما، معجزه نمی کند.
Forwarded from A.R. Aminian
This media is not supported in your browser
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
#ویدئوی_آموزشی
موضوع:
Introductory Video Series on How to Build Geometries in COMSOL®
مدت: 16 دقیقه و 02 ثانیه
حجم: 33.8MB
فرمت: MP4
@Comsol_shs
موضوع:
Introductory Video Series on How to Build Geometries in COMSOL®
مدت: 16 دقیقه و 02 ثانیه
حجم: 33.8MB
فرمت: MP4
@Comsol_shs
SIMULFA - COMSOL & ABAQUS
#ویدئوی_آموزشی موضوع: Introductory Video Series on How to Build Geometries in COMSOL® مدت: 16 دقیقه و 02 ثانیه حجم: 33.8MB فرمت: MP4 @Comsol_shs
در ویدئوی آموزشی فوق، دو فایل مساله مورد استفاده قرار گرفته است که به پیوست جهت بهره برداری مخاطبین محترم تقدیم شده است:
@comsol_shs
👇🏻👇🏻👇🏻
@comsol_shs
👇🏻👇🏻👇🏻
SIMULFA - COMSOL & ABAQUS
در ویدئوی آموزشی فوق، دو فایل مساله مورد استفاده قرار گرفته است که به پیوست جهت بهره برداری مخاطبین محترم تقدیم شده است: @comsol_shs 👇🏻👇🏻👇🏻
light_bulb.mphbin
134.9 KB
فایل مساله دوم مورد استفاده در ویدئوی آموزشی فوق
@comsol_shs
@comsol_shs
#اطلاع_رسانی
دوستانی که در زمینه پردازش سیگنال و ... تخصص یا سابقه پژوهشی خوبی دارند می توانند از این فرصت استفاده کنند.
دوستانی که در زمینه پردازش سیگنال و ... تخصص یا سابقه پژوهشی خوبی دارند می توانند از این فرصت استفاده کنند.
This media is not supported in your browser
VIEW IN TELEGRAM
#ویدئوی_آموزشی
موضوع:
COMSOL Conduction heat transfer: Heat Loss through an Insulated Steam Pipe
مدت: 07 دقیقه و 04 ثانیه
حجم: 8.96MB
فرمت: MP4
@Comsol_shs
موضوع:
COMSOL Conduction heat transfer: Heat Loss through an Insulated Steam Pipe
مدت: 07 دقیقه و 04 ثانیه
حجم: 8.96MB
فرمت: MP4
@Comsol_shs
👍2
This media is not supported in your browser
VIEW IN TELEGRAM
#ویدئوی_آموزشی
موضوع:
Simulation of a Pitched Blade Turbine Impeller in Comsol Multiphysics
مدت: 03 دقیقه و 52 ثانیه
حجم: 7.05MB
فرمت: MP4
@Comsol_shs
موضوع:
Simulation of a Pitched Blade Turbine Impeller in Comsol Multiphysics
مدت: 03 دقیقه و 52 ثانیه
حجم: 7.05MB
فرمت: MP4
@Comsol_shs
Media is too big
VIEW IN TELEGRAM
#ویدئوی_آموزشی
#وبینار
موضوع:
COMSOL Webinar: Modeling Non-Linear Structural Materials
مدت: 22 دقیقه و 29 ثانیه
حجم: 36MB
فرمت: MP4
@Comsol_shs
#وبینار
موضوع:
COMSOL Webinar: Modeling Non-Linear Structural Materials
مدت: 22 دقیقه و 29 ثانیه
حجم: 36MB
فرمت: MP4
@Comsol_shs
Media is too big
VIEW IN TELEGRAM
#ویدئوی_آموزشی
موضوع:
Laminar Flow Simulation in COMSOL Multiphysics
مدت: 12 دقیقه و 53 ثانیه
حجم: 22.9MB
فرمت: MP4
@Comsol_shs
موضوع:
Laminar Flow Simulation in COMSOL Multiphysics
مدت: 12 دقیقه و 53 ثانیه
حجم: 22.9MB
فرمت: MP4
@Comsol_shs