-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
msh.make_bc
api
#213
Comments
Hi @krober10nd I have made a multiscale mesh that followed your suggestion. mshopts = meshgen('ef',{fh_NSCS,fh_PRE},'bou',{gdat_NSCS,gdat_PRE},'plot_on',1,'proj','lam','nscreen',1); It works well. Now, I am making the open boundary condition. m = make_bc(m,'auto',gdat_NSCS); However, several open boundaries appeared in places that they should not have appeared. Any suggestions to fix it? Thanks! |
I would try to use the 'delete' option in the make_bc function but it seems to be used to delete the boundaries rather than open boundaries. |
Ah yea this is exactly why I had proposed this issue. You'll need to likely pass both depth and distance bounds. The probable issue is your river extends sufficiently far overland that the distance criteria is being met to classify as an ocean boundary. ''' Where 'distance' indicates the distance in geographical degrees from the mainland, 'depth' indicates the depth that's sufficient to classify the node as an open ocean boundary, and 'length' is the minimum number of nodes to classify as an open boundary. It's tricky I know but automatic classification of boundaries with meshes with rivers isn't easy. See also the doc string for more information Yes the delete option only deals with land/no flux boundaries |
By the way, experience also tells me you'll probably need more nodes per width of those rivers to get flow up. I'd suggest a minimum of 4 for the feature size and make sure to change your minimum element size too. |
Thanks for your reply. After several tries, the open boundaries can be automatically classified well. m = make_bc(m,'auto',gdat_NSCS,'both',0.1,20); I used the above parameters, the result looks fine. |
About meshing the river domain, thanks for your suggestion about the feature size parameter. I did use the feature size of 3 in the current mesh. Actually, I am just making the nested mesh at the moment, and I don't use this nested mesh to run an adcirc simulation yet. I will try to use a bigger feature size for the river domain. Thanks for the suggestion again. |
Okay, yea, since ADCIRC uses P=1 linear elements, the representation of the river channel is piecewise linear so it can be quite crude with only 3 or 4 elements across it's width. If the region you're modeling has large tides, sections of the coarsely resolved river may go artificially dry and lead to numerical instabilities. |
Thanks, I can understand what you have said above. Wait for me to test meshes with different feature sizes and min_els to run an adcirc simulation. Perhaps the effect or sensitivity of mesh resolution placement on the accuracy and speed of the simulation in the river domain may be an interesting issue. I did not notice any article or report about this issue, because adcirc are mainly used to model in the ocean domain. By the way, it must be admitted that the function of feature mesh size in OM is very powerful, it uses an approximate medial axis to help mesh. I have read the paper you have cited (Jonas Koko: A Matlab mesh generator for the two-dimensional finite element method). I guess there is no other better tool that can mesh the river network easily and quickly. See the figure below, although the feature size needs to be further increased, it does not affect the performance of placing sufficient resolution in channels of different widths. |
make_bc
. For example showing how to use both depth and distance bounds to label boundaries.The text was updated successfully, but these errors were encountered: