- 세상의 모든 계산기 자유(질문) 게시판 일반 ()
[계산] 농업용 스프린클러 3개 설치시 면적? 살수량? 관수량? 강수량?
-
- 2024.07.15 - 18:31 2024.07.02 - 16:46 790 3
https://kin.naver.com/qna/detail.naver?d1id=11&dirId=1113&docId=471948019
농업용 스프링클러 3개를 이렇게 배치하고
분당 100L에 20m 거리를 살수하는 스프링클러를 한시간 동안 사용하면
저 면적에 약 15mm정도의 물이 살수된다고 하는데
이때 면적은 얼마만큼의 면적을 말하는 걸까요
2번 3번 겹치는 곳은 한번 겹친다고 보는 건가요?
살수량 = (100L/min X 60min) / (0.866 X 20 X 20) 해서 대충 15 나온다
그리고 잘 기억은 안나는데 0.866이면 사인값인 것 같고
무튼 스프링클러 하나만 생각하면 시간당 6000L = 6톤 = 6m^3인데
15라는 값 같으면 4 정도로 나뉘어진다는 거일텐데
단순히 원면적인 πR^2는 아닌 것 같고 해서 질문드립니다
-
25
댓글3
-
세상의모든계산기
아무래도 최소 숫자로 최대의 면적을 커버하는 최적의 공식이 이미 있을 것 같은데...
당장 검색이 잘 안되니 일단, 문제에 집중해 보겠습니다.
문제에서는 아무리 봐도 3개 원의 교점이 원의 중심을 지나는 것을 가정하는 듯 보입니다.
그렇지 않다면... 어쩔 수 없구요.
- 노란 정삼각형 면적 = area_t
- 빨간 호의 면적 = area_a
- 원(1개)의 면적을 = area_c
- 물이 1번 뿌려지는 3개 부분 중 한 부분의 넓이 = s1
- 물이 2번 뿌려지는 3개 부분 중 한 부분의 넓이 = s2
- 물이 3번 뿌려지는 부분의 넓이 = s3
- 라고 하면 각 면적은 아래와 같이 계산됩니다.
질문하신 내용 중에 0.866*20*20 부분은 삼각형 2개의 면적과 같은데...
무슨 공식이 있는 것인지는 모르겠으나, 무슨 근거인지 갸우뚱하네요.
스프링클러 1개에서 1시간동안 나오는 물의 양을 w_hour 라고 하면
전체 면적 평균으로 내면 대략 7mm 강수량에 해당하고,
스프링클러가
1번 만 지나가는 부분의 강수량은 w1 = 4.77mm
2번 지나가는 부분의 강수량은 w1*2 = 9.55mm
3번 지나가는 부분의 강수량은 w1*3 = 14.32mm
15mm 라고 계산한 것은 3번 지나가는 한 가운뎃 부분의 강수량과 얼추 비슷한데,(지금 추정하기로는) 물이 제일 많이 먹게되는 곳의 강수량을 쉽게 계산하기 위한 편법공식같은게 아닐까 싶네요. -
세상의모든계산기
1번 뿌려지는 강수량/시간 을 3번 곱하지 않고,
왜 삼각형*2개로 계산했는가를 곰곰히 생각해 보니,
삼각형 2개로 계산하는게 맞네요.
: 3번씩 뿌려지는 부분이 중복에 중복이라 다시 3번 뿌려지는 면적에서 빼야 하는데, 그것이 결국 삼각형 모양이 되고,
합쳐지면 정육각형 벌집모양으로 완결됨.
설치하는 스프링클러 갯수가 많아질수록
정육각형을 가정하는 편이 계산도 편해지고, 오차가 줄어듭니다.
예) 비현실적이지만, 가로 100,000 줄, 세로 100,000 줄로 스프링클러를 배치하면
대략 이렇게 되겠죠.
1번 또는 2번 겹치는 부분을 제외하면 사각형으로 봐도 될 것이고,
1번 또는 2번 겹치는 외곽부분까지 대충 포함하더라도 평균 강수량(mm) 에는 별 차이가 없게 됩니다.
세상의모든계산기 님의 최근 댓글
예시11) 선형 연립방정식에서 답이 false 로 나올 때 https://allcalc.org/55823 2025 10.22 approx(참 해) 값이 이상하게 튀는 것 같아서 AI를 이용해 (python 으로) 구해보았습니다. * python 의 유효자릿수가 nspire 의 유효자릿수(14자리~15자리)보다 더 길기 때문에 시도하였습니다. ** 원래는 wolfram alpha 로 구해보려고 했는데, 울프람에서는 수식 길이가 너무 길다고 거부하는 바람에 포기하였습니다. 그 결과, AI approx(참 해) 값은 정상 범주에 포함되었고, 이는 solve()로 구한 대부분의 결과값과 유사하였습니다. 그럼 nspire 의 approx(참 해)는 왜 튀었나? 참 해에 더하기,빼기,곱하기,나누기 가 너무 많이 포함되어 있다보니, 모두 계산하고 나면 오차가 누적&증폭되어 버리는 것 같습니다. 그래서 오히려 solve의 numeric 한 접근보다도 더 큰 오차가 발생한 듯 하고, 그래서 적절한 해의 x 구간을 벗어나버린 듯 합니다. 그것이 처음의 solve 에서 false 를 이끌어낸 주 원인이 아니었을까요? (추정) 2025 10.21 그래프로 확인 그래프 함수로 지정하고, 매우 좁은 구간으로 그래프를 확대해 보면 불연속적인 그래프 모습이 확인됩니다. 이것은 한계 digits(15자리) 이상을 처리하지 못하기 때문일 것이구요. 다만 특이한 점은, 그래프상으로 교점에 해당하는 구간이 73.049507058477≤x≤73.049507058484 사이로 나오는데 -> 이 구간은 'solve에서 여러 방법으로 직접 구해진 해들'은 포함되는 구간입니다. -> 하지만, '참값인 해를 계산기로 구한 appprox 값 x=73.049507058547'은 포함되지 않는 구간입니다. 2025 10.21 tns 파일 첨부 sol_num_vs_exact.tns 2025 10.21 검증하면 1번 식을 x에 대해 정리하고, → 그 x 값을 2번 식에 대입해 넣으면 → 그 결과로 x는 사라지고 y에 대한 식이 되니, y에 대해 정리하면 참값 y를 얻음. 얻은 y의 참값을 처음 x에 대해 정리한 1번식에 대입하면 참 값 x를 얻음. 구해진 참값의 근사값을 구하면 x=73.049507058547 and y=23.747548955927 참 값을 approx() 로 변환한 근사값은 원래 방정식 모두를 만족할 수 없지만, linsolve() 로 찾은 근사값과, AI로 참 값을 근사변환한 값은 원래 방정식 모두를 만족할 수 있습니다. 2025 10.21