Talk:Mass flow meter

Untitled
Maybe the page should specify that it's not about Mass Flow Meters in general, but just one particular operating principle.... —Preceding unsigned comment added by 64.69.111.10 (talk) 20:17, 26 January 2011 (UTC)

Shrinking/thumbnailing animations in an article is wasteful
I'd like to explain some more about animations.

when an image is thumbnailed the image is not shrunk once. When an image is thumbnailed the Wikipedia servers ship the original image to the requesting browser, and the browser then has to shrink the image down to the specified size.

This results in loss of quality, because the image shrinking by the browser is very crude as compared to what dedicated image processing software can do. In the case of a true thumbnail that is not a problem, the thumbnail is not the primary view. Thumbnailing is for overviews only.

But in an article, thumbnailing an animation is unacceptable. A GIF-animation consists of a sequence of individual images, that are shown in rapid succession to create the motion effect. When an animation is thumbnailed the receiving browser has to shrink down each individual frame. The result is looks bad, because the shrinking is crude, and it is a waste of bandwidth; the full sized version has been shipped out.

In many parts of the world people are still dependent on dial-in internet. Wasting bandwidth makes Wikipedia less accessible to people in developing countries. I am in favor of keeping Wikipedia as accessible as possible. I want to avoid a situation where Wikipedia is privileged to people with high bandwidth internet connection. --Cleonis | Talk 09:48, 12 April 2009 (UTC)

Hello Cleonis,

I am most definitely for accessible content, I remember my dialup days all too well. However, I must disagree with some of your statements above, specifically:


 * when an image is thumbnailed the image is not shrunk once. When an image is thumbnailed the Wikipedia servers ship the original image to the requesting browser, and the browser then has to shrink the image down to the specified size.

This is not what happens. Please read Image_markup. Quoting from this page one finds:

''Specifying a size does not just change the apparent image size using HTML; it actually generates a resized version of the image on the fly and links to it appropriately. This happens whether or not you use size in conjunction with thumb.''

Thumbnails are used all over wikipedia, and are part of the MOS' guidelines for proper article formatting.

'' Generally, use the thumbnail option ("thumb"), which is available in the image markup. This results in a default width of 180 pixels (140 pixels if the "upright" option is used as well), although logged-in users can set a different default in their user preferences. As a rule, images should not be forced to a fixed size (that is, one that overrides the default). Where it is appropriate to force size, images should generally be no more than 300 pixels wide, so that they can be comfortably displayed on 800x600 monitors. '' User A1 (talk) 11:58, 12 April 2009 (UTC)
 * I have studied the Image_markup page.
 * Interestingly, when a thumbnailed image of a JPG file is served by wikipedia, it is typically served with a different filename. For instance, when a 180px thumbnail is specified, then in the URL of the thumbnailed image the original filename is preceded by the downsized image width, making the URL look as follows:
 * http://upload.wikimedia.org/wikipedia/commons/thumb/3/39/Westminstpalace.jpg/180px-Westminstpalace.jpg
 * This is consistent with the image being served from a thumbnail cache.


 * In contrast with that, if the picture is an animated GIF (and the wiki markup specifies thumbnailing) then the animation is not modified and it is not served from a cache; the original is served.


 * The conclusion must be that the centralized downsizing and caching of thumbnails does not extend to animated GIF. It seems to me that this state of affairs ought to be documented on the Image_markup page. --Cleonis | Talk 12:31, 12 April 2009 (UTC)


 * Checking this again, I see that you are indeed correct. I will update the image_markup page at some time soon. Thankyou for taking the time to point this out.User A1 (talk) 22:27, 12 April 2009 (UTC)


 * The image_markup page redirects to the extended_image_syntax page
 * I have made two edits to the extended_image_syntax page. Check out the page history
 * Anyway, I was previously unaware that thumbnails of still images (jpg, png, gif) are downsized server side, and cached.
 * About the accessibility. A recommendation, I noticed, is to allow in article layout for users with an 800x600 monitor. In wealthy parts of the world that 800x600 has become rare, but in poorer parts of the world 800x600 may still be prevalent. Do you recommend that I manufacture smaller animated GIFs? --Cleonis | Talk 23:12, 12 April 2009 (UTC)

Reverted to using the 256x256 versions of the animations
It is considered bad practice to use images that are too large, as they tend to disrupt the layout of the page.

Let me recapitulate some things about duplicated images. The wikimedia software resizes static images automatically. That is, it suffices to upload a single large JPG or PNG file, and when you use the image in a page you can specify any smaller size than the size of the uploaded version. The wikimedia software will resize the image, it will cache the resized version, and when users view the page the wikimedia software will ship the smaller version.

But the wikimedia software does not resize animated GIFs. The 512x512 versions are not for inclusion on the wikipedia page, they have been uploaded to be available for classroom teaching purposes. If wikipedia policy is against multiple versions of animateds GIFs then the larger versions shouls be deleted, not the smaller versions. --Cleonis | Talk 09:38, 4 October 2009 (UTC)

Annual Stupid Question
Do these Coriolis effect mass flow meters work at the equator? We typically use a rotating frame of reference, but here it seems we're using an oscillating frame. Ergo, any meter of this design would work at any latitude without having to fiddle with the calibration. Watchwolf49z (talk) 14:56, 1 January 2013 (UTC)


 * I found my answer, it's yes, these meters work fine at the equator. I'm posting my reference, as it looks good, perhaps it will be of future use to this article: http://www.omega.com/literature/transactions/volume4/t9904-10-mass.html.  I propose adding this reference to the "External Link" section.  I may not be back here to make this change, so anyone can after a few weeks. Watchwolf49z (talk) 01:29, 9 January 2013 (UTC)

Revert
My apologies to Resinoth, but we should vet the information here first. If you have a reference on this information, I sure would like to read it. We already have a flag on the citations, I think any NEW information should be fully referenced. I say up-front, I think this information should be in it's own section, and not in the introductory section. It's more complex that what is there, so makes for clunky prose. I'd also like to know why you think this is notable, as generally it is the volume of the fluid we wish to measure. Watchwolf49z (talk) 01:29, 9 January 2013 (UTC)

Vibration flow meter animation - query over flow-direction and phase-shift
Is the flow-direction and phase shift correct in the vibrating meter animation? It would seem more intuitive that the downstream-part would be phase-delayed rather than phase-advanced...? It seems to be universally accepted that this is in fact correct - perhaps some more explanation is due? Andrew 217.33.180.66 (talk) 18:07, 18 November 2014 (UTC)

Assessment comment
Substituted at 23:24, 29 April 2016 (UTC)